Improve shielded sync

[sug0]

Describe your changes

• Build commitment tree and witness map locally
  • Uses leanbridgetree crate for this purpose
  • If the number of blocks to sync exceeds a certain threshold, we race with the local approach, by fetching the commitment tree, witness map and notes index in the background
    • Whatever finishes first is the data we store in the shielded wallet (which should have been identical, regardless of being built locally or fetched from the MASP indexer)
• Fix block index not being properly used
  • This is the major source of the speed-up in this PR
• Optimize the layout of the shielded wallet
  • Removed unnecessary fields
• Only fetch block index after a threshold of $N$ blocks (where it makes sense latency wise to wait for that network query vs. fetching $N$ potentially empty blocks)

Checklist before merging

• If this PR has some consensus breaking changes, I added the corresponding breaking:: labels
  • This will require 2 reviewers to approve the changes
• If this PR requires changes to the docs or specs, a corresponding PR is opened in the namada-docs repo
  • Relevant PR if applies:
• If this PR affects services such as namada-indexer or namada-masp-indexer, a corresponding PR is opened in that repo
  • Relevant PR if applies:

[sug0]

this is currently crashing when calling remove_mark in integration tests

[mergify]

🧪 CI Insights

Here's what we observed from your CI run for f97031a.

✅ Passed Jobs With Interesting Signals

Pipeline	Job	Signal	Health on main	Retries	🔍 CI Insights	📄 Logs
Lint 🧹 Build 🛠️ Test 🚦	test-integration	Base branch is broken, but retries were needed. Could be early signs of flakiness 👀		1	View	View

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[mergify]

This pull request has been removed from the queue for the following reason: checks failed.

The merge conditions cannot be satisfied due to failing checks:

• ❌ test-e2e (2)

You can check the last failing draft PR here: #4888.

You may have to fix your CI before adding the pull request to the queue again.
If you update this pull request, to fix the CI, it will automatically be requeued once the queue conditions match again.
If you think this was a flaky issue instead, you can requeue the pull request, without updating it, by posting a @mergifyio requeue comment.

[mergify]

Hey @sug0, your pull request has been dequeued due to the following reason: CHECKS_FAILED.
Sorry about that, but you can requeue the PR by using @mergifyio requeue if you think this was a mistake.

[sug0]

@Mergifyio requeue

[mergify]

requeue

✅ The queue state of this pull request has been cleaned. It can be re-embarked automatically