Remove speculative context

[grarco]

Describe your changes

Closes #4074.

Removes the speculative shielded context and the shielded-sync cli command. The shielded-sync operations is now embedded directly in the cli commands that need it:

• Shielded transfer
• Unshielding transfer
• IBC transfer (when the source is shielded)
• Balance query (for shielded owners)
• Shielded rewards estimate

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: Remove speculative shielded context namada-docs#459
• 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:

[mergify]

🧪 CI Insights

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

✅ Passed Jobs With Interesting Signals

Pipeline	Job	Signal	Health on main	Retries	🔍 CI Insights	📄 Logs
Lint 🧹 Build 🛠️ Test 🚦	test-e2e (0)	Base branch is broken, but the job passed. Looks like this might be a real fix 💪		0	View	View
	test-e2e (1)	Base branch is broken, but the job passed. Looks like this might be a real fix 💪		0	View	View
	test-e2e (2)	Base branch is broken, but the job passed. Looks like this might be a real fix 💪		0	View	View
	test-e2e (3)	Base branch is broken, but the job passed. Looks like this might be a real fix 💪		0	View	View
	test-e2e (4)	Base branch is broken, but the job passed. Looks like this might be a real fix 💪		0	View	View
	test-integration	Base branch is broken, but the job passed. Looks like this might be a real fix 💪		0	View	View

[sug0]

can we bring back the standalone shielded sync command?

[grarco]

Dropped the commit that removed this command, it's back now, I will also update the docs

[grarco]

Done in namada-net/namada-docs@fcdb251

[sug0]

oh one thing this might "break" is ctrl+c after running the implicit shielded sync, because it installs a SIGINT handler that overrides the default handler. if an rpc is hanging, we might not be able to ctrl+c out of namadac

[grarco]

oh one thing this might "break" is ctrl+c after running the implicit shielded sync, because it installs a SIGINT handler that overrides the default handler. if an rpc is hanging, we might not be able to ctrl+c out of namadac

Right, I think we could fix this in two ways:

1. We could launch the implicit shielded-sync function in a child process and wait on it. The custom handler for SIGINT should be relative to the child only and rpcs shouldn't block the submit_* functions anymore
2. We just uninstall the custom handler after we are done with the sync process

I've added the do-not-merge label for now until we have a fix for this

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[sug0]

@grarco I kinda like the first option, despite it being a bit hacky; from namada_apps_lib, we can assume we are executing one of our binaries, so the first value of std::env::args() will give you the executable path (either namada or namadac), from which we should be able to invoke shielded-sync