Bump trie-db to 0.27.1 (fix storage iteration bug + change seek behavior with prefix)

[koute]

This PR bumps trie-db to version 0.27.1 (see this PR for details) which mainly changes two things:

1. It fixes a bug with storage iteration where in certain cases the iterator would return keys outside of the specified prefix (see this issue for details)

2. It changes how the iterator works when both a prefix and a key from which to start iteration from is specified. This cleans up some corner cases and solidifies the behavior of how the iteration works which, AFAIK, previously was entirely accidental. The iteration now always follows the following two rules:

   • All of the keys returned by the iterator are guaranteed to start with the specified prefix (if present).
   • All of the keys returned by the iterator are guaranteed to be equal or bigger lexicographically to the starting key (if present).

Tagging this as B1-note_worthy and C3-medium for RPC nodes; everyone else can most likely treat this as C3-low.

Fixes polkadot-js/apps#9103

Side-note

As far as I can see this shouldn't affect runtime behavior yet as the host functions (clear_prefix and storage_kill) to access this from within the runtime are not actually used (they're marked as register_only). That said, after merging this PR we will have to wait until the nodes are upgraded before we can consider removing the register_only flag from those host functions. (Since the host function is technically exposed; it's just not used by the runtime. This is why I've tagged this E3-host_functions even though it shouldn't affect the current runtime.)

[cheme]

Certainly should be deployed as soon as possible, but medium sounds right to me. If another pr is running a burn in, can be an idea to include this one, but I don t think it is really needed.

[koute]

Certainly should be deployed as soon as possible, but medium sounds right to me. If another pr is running a burn in, can be an idea to include this one, but I don t think it is really needed.

Hmm... well, it should be fine, but I guess I can probably leave a full burn-in + partial burn-in (from the current chain head) with this applied over the weekend and see how it goes, just in case.

[cheme]

Certainly should be deployed as soon as possible, but medium sounds right to me. If another pr is running a burn in, can be an idea to include this one, but I don t think it is really needed.

Hmm... well, it should be fine, but I guess I can probably leave a full burn-in + partial burn-in (from the current chain head) with this applied over the weekend and see how it goes, just in case.

For me it is not essential, let's get others opinion :)

[koute]

For me it is not essential, let's get others opinion :)

Essential or not I'll do it anyway purely just for my own peace of mind. (: You can never have enough testing.

[koute]

bot merge