implement 'DataManager' and use it throughout the codebase

[instamenta]

** DRAFT **

Description

Currently we have a lot of logic spread out throughout the codebase, a lot of places utilize different methods to get the same data and it has become hard for getting the data since it's spread and comes from different places. For this reason we need to make a new class DataManager which would serve as a single source of truth.

Class Interface

export abstract class IDataManager {  
  public namespace: NamespaceName;  
  public deployment: DeploymentName;  
  
  public contextNames: ContextName[];  
  public clusterRefs: ClusterRef[];  
  public contextClusterMapping: Record<ContextName, ClusterRef>;  
  public clusterContextMapping: Record<ClusterRef, ContextName>;  
  
  public abstract nodes: ConsensusNode[];  
  public abstract existingNodes: ConsensusNode[];  
  public abstract nodeAliases: NodeAlias[];  
  public abstract existingNodeAliases: NodeAlias[];  
  
  public abstract leases: Lease[];  
  
  public abstract config: AnyObject;  
  
  /** To make it extensible and for type-safety, this method would be used when config data is needed */  
  public abstract getConfig<T>(): T;  
  
  public abstract readonly argv: AnyObject;  
  
  /** Flags that come from default values instead of passed via cli */  
  public abstract defaultFlags: CommandFlag[];  
}

[jeromy-cannon]

I had a discussion with Nathan yesterday about our Data Manager. Not specifically what you have hear, this is the first time I saw it.

We believe this is a good way to split up the data types:

• generated persisted data (files in SOLO_CACHE_DIR)
• constants (real constants, not the ones that can be overridden by environment variables) (immutable for all properties/values if it is an object or array)
• configuration
  • non-persisted
    • yargs + argv
    • prompting user for value
  • persisted
    • from environment variables with defaults (shouldn't be constants) (persisted and non-persisted)
      • persist to local-config or remote config or separate file (needs more design)
    • persisted by being: saved to remote config, cluster, or local config
• run-time
  • introspected (from a cluster or other source)
  • computed (nextNodeId, FQDN)
  • hybrid? NetworkNodeServiceMap (split into two?)

Sources of data:

• environment variables
• CLI args / yargs / argv
• local config
• remote config
• mutable context config should be separated out
• adding things to argv should not be happening
• flags should be immutable, mutable setting should be removed

More notes:

• argv should not be mutated, see helper.ts.addFlagsToArgv
• argv should not be mutated, see references to how baseCmd.getConfig() has a 2nd paramater of argv.flags
• also, we should remove baseCmd.getConfig()
• ensure that we always follow this order with the configurations: 1) user flags, 2) environment variables, 3) constant defaults