Graceful session migration

[kixelated]

I initially added a recommended session migration algorithm in #264. However it's too prescriptive and non-normative and I removed it. However I do think we should talk about what it takes to gracefully migrate a MoqTransport session, if it's non-obvious and should be in the draft (maybe an appendix), and if we need more mechanisms in the protocol.

This recommended algorithm requires servers to not error on a duplicate ANNOUNCE. It also results in an RTT where duplicate OBJECTs will arrive on both sessions, which is not necessarily ideal. Here's the original text before I removed it:

Graceful {#session-migration-graceful}

A graceful session migration involves migrating all subscriptions between
sessions without impeding data flow. The application should be unaware that
a session migration even occured.

The client SHOULD establish the new MoqTransport session in the background
since it may take a few round trips to resolve the address and perform any
handshakes. Once the the new session is established, any active subscriptions
and announcements are removed from the old session and issued on the new
session.

An endpoint MAY choose to abruptly transition between sessions. However it is
RECOMMENDED that both sessions are simultaneously active for a brief window
while subscriptions are individually migrated. The client and server migrate any
active announcements and subscriptions depending on their role(s) as covered
below.

The client terminates the old session once there are no more active
subscriptions or announcements. The client MAY choose to delay if OBJECTs are
still being sent/received as queues are drained, but should be prepared to
receive a GOAWAY Failure from the server if it waits too long.

Publisher

A publisher needs to migrate all active announcements to the new session. For
each active announcement:

1. The publisher sends an ANNOUNCE on the new session.
2. The publisher receives an ANNOUNCE_OK on the new session.
3. The publisher sends an UNANNOUNCE on the old session.
4. The publisher receives an ANNOUNCE_ERROR on the old session, acknowledging
   the UNANNOUNCE.

Once these steps are complete, new subscriptions will arrive on the new session
instead of the old session. The publisher may receive new subscriptions in the
meantime which should be served normally.

Subscriber

A subscriber needs to move all active subscriptions to the new session. For each
active subscription:

1. The client sends a SUBSCRIBE message on the new session, starting one past
   the maximum received object sequence.
2. The client sends an UNSUBSCRIBE message on the old session.
3. The client receives a SUBSCRIBE_OK on the new session.
4. The client receives a SUBSCRIBE_ERROR on the old session, acknowledging the
   UNSUBSCRIBE.

The SUBSCRIBE and UNSUBSCRIBE are sent in parallel to avoid underutilizing the
network, however this results in overutilizing the network for at least an RTT.
The endpoint may receive duplicate OBJECT messages across both sessions which
MUST be discarded.

[ianswett]

I think it'd be useful to have a PR to look at if you're willing to write one up?

[ianswett]

Closed by #525