Improve naming and structure in configuration

[mzabaluev]

Tracking issue: #480

The names used in configuration files (in Rust code understood as a hierarchical serde schema) should be reviewed to be consistent and concise.

• Example: indexer.grpc.hostname is more usable than maptos_indexer_grpc_connection_hostname.
• In TOML, JSON, and YAML, config structs form hierachical sections grouping related values. A TOML user additionally has the alternative to use qualified paths.

[l-monninger]

So, for posterity, the reason for names like this maptos_indexer_grpc_connection_hostname was global uniqueness, similar to the reasoning behind protobuf naming conventions.

If we have global uniqueness over relevant fields, we can merge configs (as we currently do). Merging configs helps maintain a single source of truth and ease composability.

Can you present examples or type-level representations of your proposed alternatives?

[mzabaluev]

My proposal is basically the config structures we're using now, composed structurally without the globalizing wrappers and #[serde(flatten)].

What's the use case for merging configs into a flat namespace?

[mzabaluev]

The configuration sources should conform to a hierarchy, copying the pseudo-Javascript from #385 (comment):

cliArgument ?? configFileField ?? environmentVariable ?? defaultValue;

For the config structures discussed here, we can formulate the following requirements:

1. Should implement serde to read from config files;
2. The Default impl for structs should get default values from the environment, falling back to default values (i.e. use the functions defined with godfig::env_default!)
3. The #[serde(default = "....")] fallbacks for scalar fields should use the same defaults as 2.

Overriding config values with CLI arguments is done in the respective CLI crates above the config level. I don't think there should be a generic system for this besides perhaps reusing FromStr implementations to parse parameters.