Storage has its own BlockId which excludes the Pending variant. This is because storage has no concept of pending data since it is stored ephemerally in memory.

Historically, pending data was completely disconnected from the data on disk but this led to consistency issues as it is difficult to synchronize memory and database transactions. This was solved by requiring a database transaction to unlock the pending data - it is only unlocked if the pending data is valid in the context of the latest block on disk for the given transaction.

Pending data currently lives in RPC as this is the only place in which it is used. The downside of this has been that pending queries always have a different logic path in each RPC method, and that RPC block ID needs special casing to become the storage's block ID.

We can solve this by moving ownership of PendingData from RPC to the Storage crate. This lets us use the common BlockId type every as storage can now handle BlockId::Pending queries.