Make every RecordingId typed and preclude the existence of 'Defaults'

[jleibs]

What

After talking over the confusing edge cases with @teh-cmc around "where/how do we end up with unknown recording types and unknown recording-ids" I decided to go ahead and force everything to be explicit. This simplifies a number of edge-cases related to blueprint-recordings.

• Every RecordingId now includes the RecordingType. You cannot create a RecordingId without specifying the type. There is no default for RecordingId.
• Every LogDb also knows it's RecordingId. You cannot create a LogDb without knowing it's RecordingId. This adds a bit more pain to the process of creating a LogDb, but again means you don't have to worry about having a LogDb instance and not knowing it's id / type.
• Every LogMsg must have a RecordingId. This meant adding a RecordingId to the Goodbye message.
• The selected_recording_id instead is now Optional. You can only select a valid recording.

Overall, this makes some things a bit more verbose, but generally seems to improve the clarity by reducing the number of places we end up doing work with unexpected ephemeral log-dbs for an unknown recording of an unknown type.

Checklist

• I have read and agree to Contributor Guide and the Code of Conduct
• I've included a screenshot or gif (if applicable)

PR Build Summary: https://build.rerun.io/pr/2110

[teh-cmc]

Looks fantastic! My only gripe is the fact that the transport implementation has a say in when and what kind of app messages get sent (a problem that predates this PR), which now results in a bunch of awkward piping of the RecordingId.

I think we can fix both problems with very little effort by putting RecordingStream in charge of the Goodbye message?

See inline comments.

[teh-cmc]

Addressed my own comments so I can build on top of this for #2061.

I cannot put you as reviewer because you're the author @jleibs, but I'm implicitly doing so :)

[teh-cmc]

Fixing the broken test :slow_beach_ball:

[teh-cmc]

This now sends a Goodbye message anytime you call disconnect(), or if you drop the stream altogether.

While I like it better than what we had before, I'm certainly not satisfied with this... in the future I wonder if we shouldn't have a mirrored relationship between OpenedSink (roughly what we call BeginRecordingMsg today) and ClosedSink (i.e. Goodbye) and always send them as we swap a new sink in and out, respectively.
Not only the symmetry would get rid of the fact that the TCP sink currently play by its own rules, it would also open some opportunities UI-wise I think.

[jleibs]

Nice cleanup; sending from the Stream is a much better solution. Thanks!