Handle coherence between InMemory modules

[jimmarino]

@paullatzelsperger When an asset is added to the AssetIndex, shouldn't it only be visible once the InMemoryDataAddressResolver has an entry? In other words, how is the following avoided:

1. AssetIndex is updated with an Asset
2. A request for the asset starts processing and the DataAddress is needed
3. The DataAddress is added for the Asset

Similarly, how are Assets and DataAddresses flushed/removed from the system?

You could enforce an ordering where DataAddresses are added first (flip 1&3 above), but then what does the ordering? Or implement both interfaces in a common service.

[ndr-brt]

likewise to #167 i think the "write responsabilities" on this two data sets will be outside the connector, as the AssetIndex and DataAddressResolver interfaces stated.
We should for sure handle failing cases but on the reading side, e.g.:

• Asset retrieved but no DataAddress for it
• DataAddress retrieved but not Asset

[paullatzelsperger]

@ndr-brt i think we need to provide a form of "atomicity context". Please take a look at Issue #172 which deals with at least the in-mem case.