storage_type: Strip key proper hash and entry bytes (32 instead of 16)

[lexnv]

This PR ensures that we can properly decode storage key addresses.

There was an issue confirmed by https://github.com/paritytech/subxt/issues/1517, where the decoding of keys for dynamic storage queries would always fail at:

https://github.com/paritytech/subxt/blob/75c905dcb7ce61832d4d6395ffd2cbd7f28a89a6/subxt/src/storage/storage_type.rs#L260-L264

After investigating the code path, the error is coming from the following lines: https://github.com/paritytech/subxt/blob/75c905dcb7ce61832d4d6395ffd2cbd7f28a89a6/core/src/storage/storage_key.rs#L272-L275

The check appeared to be correct, as well as consuming hasher keys via consume_hash_returning_key_bytes.

After inspecting the key address bytes, we wrongly assumed the storage prefix bytes length.

Our storage keys start with the following:

twox_128(storage prefix) ++ twox_128(storage entry name)

In the issue, it is twox_128(System) ++ twox_128(Accounts).

The output of the twox is: 16 bytes, not 8 as stated and assumed in our code base.

Testing Done

• reproduced the issue via storage_iter_dynamic example
• Compared addr bytes with expected prefix:
  • twox_128("System"): 26aa394eea5630e07c48ae0c9558cef7
  • twox_128("Account"): b99d880ec681799c0cf30e8886371da9

Closes: https://github.com/paritytech/subxt/issues/1517

[jsdw]

Awesome; thanks for digging into this!