[enhancement] Improve Interfaces Between Components

[wilyle]

Description

Most components are using a "shared state" model (usually Arc<Mutex<T>>) to communicate data. This interface is clunky and may not even be the best approach. Consider modifying these interfaces to improve readability, maintainability. and/or performance.

The main suggestion would be to wrap usage of Arc<Mutex<T>> behind another struct where appropriate. For example, instead of using Arc<Mutex<HashMap<String, DigitalTwinMapEntry>>> in the cartographer and emitter, create a DigitalTwinMap struct which exposes methods such as get(id: String) and set(id: String, value: DigitalTwinMapEntry). The DigitalTwinMap could manage locking the resource as well, meaning that lock statements are not needed by the caller. Callers would likely just need to use Arc<DigitalTwinMap> rather than the more complex type. This wrapper can likely be made generic to avoid code duplication, and the DigitalTwinMap might extend or alias a struct such as SharedMap<TKey, TValue>.

Other things to consider:

• Refactor to have reader/writer roles. Most interfaces between components go one way where one component is updating the data and another is reading it. In this case, the "more correct" way to implement this would be with reader or writer access as appropriate.
• Refactor to avoid having to copy and maintain separate state where sensible. For example, the emitter copies data from the digital twin map into its own emissions map which has additional metadata. However, each entry in the emitter's map has a corresponding entry in the shared state with the cartographer. If the DigitalTwinMapEntry data type contained fields for this data then the copy would not be necessary, saving both CPU and memory usage. This should be balanced with the impact of truly using shared state like this since the threads accessing the data might be blocked more often, causing delays in updating this shared state.
• Refactor to avoid using Arc<Mutex<T>> as the interface between components. Possible options include a channel-based approach or a client-server-style approach. Note that most alternatives (including the possibilities mentioned) would require additional resource consumption, so this should be balanced against the benefits of such an approach.

Acceptance criteria

• Components do not use Arc<Mutex<T>> directly to share data (since there are multiple ways to realize this as noted in the description, this is the only acceptance criterion included in this issue)