coord: Make storage usage interval configurable

[jkosh44]

This commit makes the storage usage collection interval configurable, so that it is easier to test.

Works towards resolving #3739

Motivation

This PR adds a known-desirable feature.

Checklist

• This PR has adequate test coverage / QA involvement has been duly considered.

• This PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way) and therefore is tagged with a T-protobuf label.

• This PR includes the following user-facing behavior changes:

  • N/A

[benesch]

LGTM modulo nit about command line argument naming.

[benesch]

Can you make this a storage_usage_collection_interval: Duration directly and tell clap to parse it using the parse_duration crate?

[jkosh44]

We have our own parse_duration function which I think we've used in the past to parse command line arguments. Should we use that instead? Or does the crate do a better job?

[jkosh44]

@benesch The parse_duration crate is no longer being update https://github.com/zeta12ti/parse_duration

IMPORTANT: This repository is no longer being updated. Before deciding to use it, check if any of the issues are deal breakers. In particular, this crate should not be used with untrusted input (see zeta12ti/parse_duration#21).

The crate also uses an old version of the num crate. They use version 0.2.0, but the most recent version is 0.4.0.
https://github.com/zeta12ti/parse_duration/blob/089e7988b0677d31c45f5a72216abf9c5155600f/Cargo.toml#L20
https://crates.io/crates/num

This causes us to have duplicate dependencies on the num crate. We have an explicit policy not to allow duplicate dependencies, and to either update the crate upstream or fork it.

materialize/deny.toml

Lines 3 to 8 in 0357d26

	# Do not add exemptions for duplicate dependencies! Duplicate dependencies slow
	# down compilation, bloat the binary, and tickle race conditions in `cargo doc`
	# (see rust-lang/cargo#3613). Submit PRs upstream to remove duplicated
	# transitive dependencies. If necessary, use patch directives in the root
	# Cargo.toml to point at a Materialize-maintained fork that avoids the
	# duplicated transitive dependencies.

Considering that the crate is dead, do we want to fork it or go a different route?