Introduce data access recording capabilities

[frisitano]

Describe your changes

This PR introduces the required changes to support recording of data access. This includes the introduction of the following components and changes:

• KvMap: A trait that defines the interface for a key-value map.
• RecordingMap: A [RecordingMap] that records read requests to the underlying key-value map. The data recorder is used to generate a proof for read requests.
• MerkleMapT: A supertrait that defines the required traits for a type to be used as a data map backend for the [GenericMerkleStore]
• MerkleStore -> GenericMerkleStore: Made MerkleStore generic over the key value map backend.

[frisitano]

If we are unhappy with double counting then we can introduce a counter for duplicates which we deduct when len is called. To make the iter(..) method only return unique values we could use itertools or alternatively copy the Unique implementation we require .

[bobbinth]

I think we do want to handle this properly (especially for iteration) as it may affect how things work downstream. Depending on how much work it is, copying the implementation would be better (though, if it proves rather complex, adding itertools as a dependency may be OK.

Another potential alternative is to change how this data structure keeps track of updates. Specifically, it could look something like this:

pub struct DataRecorder<K, V> {
    data: BTreeMap<K, V>,
    updates: BTreeSet<K>,
    trace: RefCell<BTreeMap<K, V>>,
}

And something like get() method could then work like so:

pub fn get(&self, key: &K) -> Option<&V> {
    match self.state.get(key) {
        None => None,
        Some(value) => {
            if !self.updates.contains(key) {
                self.trace.borrow_mut().insert(key.clone(), value);                
            }
            Some(value)
        }
    }
}

This does do more work - so, not sure if it is worth it.

[frisitano]

What does state represent in this instance?

[bobbinth]

oh - sorry, state should have been data.

[frisitano]

I don't think your proposal will work. It will always return the original value even if it has been updated. I implemented an alternate scheme, this involves the introduction of updated_keys which keeps track of the keys from the original set which have been updated.

[bobbinth]

I've implemented this approach in 80a7f01 as it simplified the implementation a bit. The tests seem to be passing (and I've added some more checks) - but take a look and see if I missed anything.

[bobbinth]

I pushed a commit which simplifies things a bit. This includes:

• Refactoring of RecordingMap.
• Getting rid of some extra traits in favor of having a single KvMap trait which inherits from other traits such as Extend, FromIterator etc.
• Reorganizing crate structure a bit (i.e., moving KvMap under collections).