Migrate SDK comms to gRPC

[jprochazk]

Related

• Closes Migrate all TCP/WS comms to gRPC #8750

What

The goal of this PR is to completely delete re_sdk_comms and re_ws_comms. The prerequisite to this is to first migrate all of their usages over to our temporary gRPC server ("message proxy").

Step-by-step:

• Expose gRPC variants of spawn/connect from all SDKs
• Start a gRPC server instead of TCP server on native and connect to it by default
• Start a gRPC server instead of the re_ws_comms server and connect to it by default
• Remove all remaining usage of re_sdk_comms and re_ws_comms
• Delete re_sdk_comms and re_ws_comms

I don't really know how to split this up, to be honest! There are tons of subtle but very strong dependencies between different parts of our SDKs, the Viewer, and the "server". Breaking it apart seems too difficult, and it'd also temporarily make some parts of rerun unusable, and thus untestable. So instead I'll be trying to keep individual commits somewhat sensible and reviewable.

Testing checklist

• SDK spawn
  • C++
  • Rust
  • Python
• SDK serve
  • C++
  • Rust
  • Python
• rerun (default args) + SDK connect
  • C++
  • Rust
  • Python
• rerun --web-viewer + SDK connect
  • C++
  • Rust
  • Python
• Custom examples

[github-actions]

Web viewer built successfully. If applicable, you should also test it:

• I have tested the web viewer

Result	Commit	Link	Manifest
✅	3a4bdcc	https://rerun.io/viewer/pr/8838	+nightly +main

^{Note: This comment is updated whenever you push a commit.}

[emilk]

We should apply this fix too:

• Never drop blueprint data from the WS server's message buffer #8977

[jprochazk]

We should apply this fix too:

• Never drop blueprint data from the WS server's message buffer #8977

I'm not sure if it applies here. I explicitly added BlueprintActivationCommand to the list of things that get GC'd, so we never run into the scenario where a Viewer tries to activate a blueprint for which it has no data. The activation command is ordered after all its data, so it is safe to garbage collect.

The question is whether or not we want to garbage collect blueprints in the first place. It's reasonable to say that we don't, because it's not a ton of data compared to an actual recording.

[jprochazk]

I ended up doing just that, so we no longer GC blueprints at all

[jleibs]

Generally looks good. I'm sure there are some edge-cases that are only going to turn up in testing.

The biggest potential API-regression I see is the loss of flush_timeout behavior -- it's not totally clear to me under what circumstances data potentially gets dropped if the connection between the client and server is broken before we call flush.

[jprochazk]

One last check before merge

@rerun-bot full-check

[github-actions]

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