Implement support for fully asynchronous QueryHandles

[teh-cmc]

This adds non-blocking methods to all our new shiny storage handles, and uses these new non-blocking primitives to implement asynchronous helpers (read: Futures) in our QueryHandle.
These helpers are then used on the other side to implement a proper Stream.

In particular, all read locks are now recursive, always.
Recursive locks are mandatory for two reasons:

• As we start parallelizing the viewer further, and especially when using work-stealing schedulers, nested read locks will become a common occurrence.
• In asynchronous contexts, everything is designed around work stealing.

Checklist

• I have read and agree to Contributor Guide and the Code of Conduct
• I've included a screenshot or gif (if applicable)
• I have tested the web demo (if applicable):
  • Using examples from latest main build: rerun.io/viewer
  • Using full set of examples from nightly build: rerun.io/viewer
• The PR title and labels are set such as to maximize their usefulness for the next release's CHANGELOG
• If applicable, add a new check to the release checklist!
• If have noted any breaking changes to the log API in CHANGELOG.md and the migration guide

• PR Build Summary
• Recent benchmark results
• Wasm size tracking

To run all checks from main, comment on the PR with @rerun-bot full-check.

[teh-cmc]

@rerun-bot full-check

[github-actions]

Started a full build: https://github.com/rerun-io/rerun/actions/runs/11617886895

[jleibs]

This looks suspicious to me -- the body of that function is large and I wouldn't expect us to execute that code unless we aren't able to access self.state.

Why isn't this:

self.state.get_or_init(|| self.init_(store, cache))

[teh-cmc]

Uh-oh, nice catch. I meant to add a non-blocking optimistic check that comes first.

But now that I think about it, this is in QueryHandle, so realistically nothing will ever contend on this... we can probably just do it all in the OnceLock yeah.