Don't activate blueprint until the entire file has been received

[jleibs]

Although this is primarily intended to facilitate receiving streams from the SDK this might also simplify (#5294).

The store-hub already maintains a single active blueprint per recording id, but the logic for when / how it's activated needs to change.

A blueprint can be sent via any of Spawn, Serve, or Connect (work to be done in: #4167), or manually via file-open.

The new design is that when a blueprint is sent, regardless of origin, it will replace the currently active blueprint.

The challenge is that we don't want to activate the blueprint until we have received the whole thing. This is important for cases of avoiding mutating the blueprint with heuristics or user-edits while it's still being received which could lead to bizarre/corrupt state (side-note: we need CRDT 😭).

Possible implementations

• The fastest thing to do here could be to introduce a new LogMsg enum variant in the stream along the lines of "ActivateBlueprint" that is sent in the stream once all of the blueprint parts have been sent.
• A counter-point raised in discussion is that growing this enum means a future burden of all the custom serialization/deserialization logic for it, cross-language API routing, etc. We already have mechanisms to send generic arrow-encoded data over a permutation of (store_id, store_kind, app_id, entity_path, component). Depending on where and how we want this data to be surfaced, an approach such as reserving a special "Control plane" data destination. RecordingId or StoreKind seem like good candidates.

Related issues:

• Remove special-casing for blueprint-id = app-id #5295
• New options for setting blueprint: "force", "load if unset", "set default" #5298