Enable requesting account storage map information

[igamigo]

To enable FPI, GetAccountProofs was introduced. This endpoint returns a proof of the account's existence, alongside state headers: AccountHeader, StorageHeader and AccountCode. There is an implicit limitation to this workflow: StorageHeader only contains the top-level storage slot items (eg, for storage maps, only the root is returned, without any actual map information), so any transaction that attempts to get data related to a foreign account's storage map would fail.

A mechanism should be provided to allow querying for a specific item/key, in a way that enables FPI with procedures that look into any item, not just top-level values. I'm not sure if we would prefer to retrieve individual storage slots, or if it could be made more granular in order to request specific values of storage maps.

As a side note, if a workaround is needed with more urgency, maybe we could (in the client) get the full account object with the GetAccountDetails endpoint for now to work around this limitation.

[Dominik1999]

@Mirko-von-Leipzig @bobbinth can you prioritize this? Its a user request, and we like our users!

[Mirko-von-Leipzig]

imo we should implement the quick-fix @igamigo suggested in the client. Given that our current user-base is small the impact should be minor, and this gets the users something useable asap, without being majorly impacted by the holiday delays.

We still need to flesh out a proper design for handling arbitrarily large request ranges which would form part of the solution for this iiuc.

[igamigo]

I forgot to mention here that I did implement the quick fix on the client to unblock the pioneers.

Additionally I've added the parameters for querying account maps and map keys for each account on GetAccountProofs on #598. FPI integration tests on the client are passing (0xMiden/miden-client#645 implements these changes).

[igamigo]

Closed by #598