Terminate 2.0 replication on session delete

(From https://github.com/couchbase/sync_gateway/issues/3727)

1.x replication involves ongoing new REST API calls, so deleting a session would result in termination of the replication.

2.0 replication only makes a single REST API call (at replication start), and so a deleted session isn't detected by the ongoing replication.

We need to review whether session delete should continue to terminate replications in 2.0, with the following considerations:

When a REST API request successfully authenticates w/ a session, it refreshes/extends the expiry for that session. This meant that sessions typically didn't expire during ongoing replication in 1.x (assuming there's any traffic), so only explicit session deletes would terminate the replication. That wouldn't be the case for 2.0 - sessions will expire based on the original expiry time. If we want to maintain the previous behaviour, any periodic session check being done by the blip handlers would need to do this session extension handling as well.
One of the benefits of the new replicator is that we don't have performance overhead associated with auth, so we don't want to simply force a session check on every blip handler. We might think about watching for delete mutations for session documents on the DCP feed, and broadcasting to active replications (similar to change notification)
Currently the replication code doesn't have any insight on how a given user authenticated - just that there's an authenticated user. Should evaluate whether there's a similar scenario for other authentication methods (in particular expiry on a JWT), and design a solution that's more generally applicable