feat: Optional Storage health check

[rromanowski-figure]

Context

There is no way to verify storage backend is accessible on startup, which can make it hard to debug infrastructure configuration runtime errors. Also, the custom shell script (bin/env) for setting environment variables during local development is a non-standard approach and doesn't integrate well with Cargo's tooling.

Changes

• env: Replaced custom bin/env script with standard Cargo configuration using .cargo/config.toml with separate config files for storage backends: .cargo/fs.config.toml (file system) and .cargo/google_cloud.config.toml (Google Cloud)
• Refactored StorageConfig into its own struct for better organization
• Added health_check() method to Storage trait, runs if STORAGE_HEALTH_CHECK=true defaults to false for backwards compatibility
• Improved error messages with file path info
• Updated README organization. Added new run commands
• Add ca-certificates to docker image to resolve cert issue with google cloud

[rpatel-figure]

If I run cargo --config .cargo/fs.config.toml, does it merge .cargo/config.toml in as well? Not clear to me from the docs.

[rpatel-figure]

Should from_env verify this, for convenience?

[rromanowski-figure]

I'll just make it an enum

[rromanowski-figure]

If I run cargo --config .cargo/fs.config.toml, does it merge .cargo/config.toml in as well? Not clear to me from the docs.

Yes, from below:

The --config option may be specified multiple times, in which case the values are merged in left-to-right order, using the same merging logic that is used when multiple configuration files apply.

[rpatel-figure]

If I run cargo --config .cargo/fs.config.toml, does it merge .cargo/config.toml in as well? Not clear to me from the docs.

Yes, from below:

The --config option may be specified multiple times, in which case the values are merged in left-to-right order, using the same merging logic that is used when multiple configuration files apply.

I guess my question is if --config .cargo/config.toml is still implicit or not when --config is explicitly set, but I assume so

[rromanowski-figure]

If I run cargo --config .cargo/fs.config.toml, does it merge .cargo/config.toml in as well? Not clear to me from the docs.

Yes, from below:

The --config option may be specified multiple times, in which case the values are merged in left-to-right order, using the same merging logic that is used when multiple configuration files apply.

I guess my question is if --config .cargo/config.toml is still implicit or not when --config is explicitly set, but I assume so

Ah, from running locally, I can answer yes.

I think coupled with "Cargo allows local configuration for a particular package as well as global configuration. It looks for configuration files in the current directory and all parent directories. If, for example, Cargo were invoked in /projects/foo/bar/baz, then the following configuration files would be probed for and unified in this order:" that I read that it always uses it, but it does read slightly ambiguous