fix(rpc): Avoid possibly returning data from different blocks in z_get_treestate RPC method

[arya2]

Motivation

This avoids a concurrency bug where the z_get_treestate RPC method could return the note commitment trees for a different block than the one used to return the block hash and time.

PR Author Checklist

Check before marking the PR as ready for review:

• Will the PR name make sense to users?
• Does the PR have a priority label?
• Have you added or updated tests?
• Is the documentation up to date?

For significant changes:

• Is there a summary in the CHANGELOG?
• Can these changes be split into multiple PRs?

If a checkbox isn't relevant to the PR, mark it as done.

Solution

• Use the block hash to read Sapling/Orchard trees in z_get_treestate RPC method.

Review

Anyone can review.

Reviewer Checklist

Check before approving the PR:

• Does the PR scope match the ticket?
• Are there enough tests to make sure it works? Do the tests cover the PR motivation?
• Are all the PR blockers dealt with?
  PR blockers can be dealt with in new tickets or PRs.

And check the PR Author checklist is complete.

Follow Up Work

• BlockQuery state request?

[oxarbitrage]

thanks!

[upbqdn]

I can't see how the original code could return the wrong data. @arya2 or @oxarbitrage, could you provide more context?

[arya2]

I can't see how the original code could return the wrong data.

If the best chain changes between calls for the block data and its Sapling/Orchard trees when queried by height, it could've returned the trees for the new best chain at that height while returning the block data from the old best chain at that height.