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 #1517, where the decoding of keys for dynamic storage queries would always fail at:

subxt/subxt/src/storage/storage_type.rs

Lines 260 to 264 in 75c905d

	let keys = <Address::Keys as StorageKey>::decode_storage_key(
	cursor,
	&mut hashers.iter(),
	metadata.types(),
	)?;

After investigating the code path, the error is coming from the following lines:

subxt/core/src/storage/storage_key.rs

Lines 272 to 275 in 75c905d

	// We've consumed all of the hashers, so we expect to also consume all of the bytes:
	if !bytes.is_empty() {
	return Err(StorageAddressError::TooManyBytes.into());
	}

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: #1517

[niklasad1]

A test for iterating over storage keys would be nice :)

[jsdw]

Awesome; thanks for digging into this!