Iteration over storage items with given key prefix

[iljakuklic]

• Backend and frontend interfaces
• In-memory implementation
• Tests
• Some refactoring, mostly just moving stuff into submodules and similar

[TheQuantumPhysicist]

I think the correct way to do this is by having an Operation enum, just like in TransactionVerifier. The bonus you get there is that you can support caching read-operations by adding an extra arm, which you can exclude from writing back to db when you commit.

[iljakuklic]

Can have a look into it but preferably not as a part of the present PR. There will have to be some thought around how to mutate the data structure.The get() method now takes &self, not &mut self so some decision whether to introduce mutability into the interface or use some interior mutability mechanism would have to be made.

[TheQuantumPhysicist]

That's fair. I don't mind doing this in another PR. But I also want to point out that even without reads, mapping Some to Write and None to Erase is confusing. Let's fix this some times later with or without reads.

[TheQuantumPhysicist]

Can you please add a test of iteration that starts with a set, then deletes some items of the set arbitrarily in the middle, and then iterates again and ensures only the correct items are left?

[TheQuantumPhysicist]

Btw, I meant within and outside of a transaction.

This can be seen in multiple cases:

1. Create the data, commit, erase a subset, check, commit, check
2. Create the data, erase a subset, check, commit, check

[iljakuklic]

Btw, I meant within and outside of a transaction.

This can be seen in multiple cases:

1. Create the data, commit, erase a subset, check, commit, check
2. Create the data, erase a subset, check, commit, check

These are covered by randomised property tests but will add some normal tests as well since these tend to be easier to analyse.

[iljakuklic]

Added some more tests for deleting stuff

[TheQuantumPhysicist]

Looking good. I made some minor comments.