🛠️ [TASK] : Improved configuration handling for chain follower crate

[stevenj]

Summary

We need better and more unified configuration management for the chain follower crate, and also use as a template for other crates with configuration, so that configuration is managed with the crate that uses it.

Description

Currently the configuration is very simple, its just parameters to the functions which create either a follower, or a reader.
This is sufficient for now, but not useful long term as it will force us to consolidate configuration outside the crate its concerned with.

What I propose instead is:

1. We create a configuration structure, which can be:
   1. Initialized : Uses sane defaults, or if defined, overrides the sane defaults with pre-defined env vars to init the struct completely so that it is usable as-is. It should be intelligent, so that if we just init() we get a configuration for main-net that would "just work". If we set the network to "pre-prod" then the defaults/env vars are used for pre-prod, init etc.
   2. Builder pattern: We can use a builder pattern to "set" any of the settings in the config to new values.
   3. The struct has built in capability to serialize itself to json, and to deserialize a config.
      1. On de-serialize, any missing fields should AUTOMATICALLY be set to the appropriate sane default, OR the env var if defined. IF a field is specified that is not known, it is ignored. IF a field is specified that is known, but is wrong, we set the field to the default and also inform the caller that the config contained invalid values (and what invalid values) and that they were defaulted to these values instead.
      2. The idea here is even if we give it total junk to deserialize, it still gets a 100% valid config, and a report about why the config was junky.
      3. The cfg also has the ability to return a "json schema" that fully describes the serialized configuration, so that this can be used by the consumer.
2. Having created the config structure, it is used to initialize a Follower, or a Reader, but otherwise those interfaces have no other configuration.

So the process in code would be something like.

cfg = InitCardanoChainCfg().option()
follower = newFollower(cfg);

The cfg is re-usable, so the follower doesn't end up necessarily owning the cfg, so that it can be created once, but used multiple times. For example, a follower and a reader could use the same config after its initialized. This implies the cfg needs to be clonable.

The idea with serialization and deserialization is so that the consumer does not need to be intimately aware of what is needed to configure the follower, it can just supply a chunk of json from a combined cfg record, and if it supplies a UI to edit it, it can use the json schema to build the UI and provide proper information to the user.

Changes then to the crate and its configuration would transparently flow through the consumer, because the consumer does not care about the configuration settings, it just needs to manage them being set, saved and loaded.