Fix `TrieDBRawIterator::prefix_then_seek`

[koute]

After calling the TrieDBRawIterator::prefix_then_seek the iterator is not supposed to return any keys outside of the requested prefix; this unfortunately is not the case, and this PR fixes the issue.

Implementation notes

• Considering the complexity of the code I didn't completely trust myself to get this right, so I also added a fuzz test for this method. So far it's been running for quite a while and stopped barfing any new errors.
• For the fuzz test and for the tests I've copy-pasted the trie layout code from Substrate. The reference trie here already contains a Substrate-like trie layout, but it's not exactly the same. If I'm going to fuzz on something I'd rather do it on exactly the same thing we use in production.
• I only test and fuzz on the trie layout from Substrate. For historical reasons (e.g. we had to be Ethereum compatible in the past) the trie crate here is generic over various different layouts, but those 1) do behave differently (AFAIK some of the tests fail on other layouts), and 2) we really don't need to support those (honestly, I think we should just remove most of this flexibility as it just makes the code more complex for absolutely zero benefit to us).
• For the tests I've added a reproduction of the real-world issue that was affected by the bug this PR fixes, and also a few extra tests for anything that the fuzzer barfed while I was developing the fix.
• The case of what happens when both a start key and a prefix key is specified was not very well tested and it was mostly underspecified; now it is tested and behaves in a way that (I think) makes intuitive sense (take look at the filter in the fuzz test I added).
• Bumped the crate versions for immediate release.

Potential future work

• Refactor the rest of the tests to use the paste crate and run each trie layout as their own test instead of running every layout inside of a single test.
• Refactor the rest of the fuzz tests to use the arbitrary crate instead of manually generating the fuzz input data.
• Cut down on the genericity and simplify everything.

[cheme]

From what I read this bug is not in a host function (only clear_prefix v3 can go in the code path but it is "register_only" cc @bkchr is it possible to still use the function? (in this case I am not sure if it can be an issue since runtime will only call it with a cursor if it is not empty, and having cursor at last position do not make sense as we know it is the last position)).

[bkchr]

From what I read this bug is not in a host function (only clear_prefix v3 can go in the code path but it is "register_only" cc @bkchr is it possible to still use the function? (in this case I am not sure if it can be an issue since runtime will only call it with a cursor if it is not empty, and having cursor at last position do not make sense as we know it is the last position)).

Ahh you also came to the same conclusion as me! Good :D

[koute]

I also checked Substrate and the good thing is that we don't have the clear_prefix host functions with maybe_cursor enabled yet. So, we should not be able to have build a block with this bug? @cheme and @koute please check again that I'm right!

From a cursory look this sounds about right.

[koute]

Okay, since I want to put up a substrate PR with this fix I'll merge this now. If you'd still like for me to make any further changes feel free to leave them and I'll do them in a followup.