Transient subscriptions

[tcoopman]

This feature is needed to fix: commanded/commanded#401

TODO

• check what needs to happen for to subscribe from a disconnected state
• checkpoint_last_seen or notify_subscribers probably needs to be changed as well
• add more tests
• add to documentation

I guess a transient subscription can never get in a disconnected state, because the AdvisoryLocks are only used for saved subscriptions.

In theory checkpoint_last_seen doesn't need to be changed, because the update statement will not fail, but changed it as well so we don't even try to update.

To discuss

Because we don't store anything, it's possible to:

1. start a persistent subscription with name "foo"
2. have it killed and later start a transient subscription with name "foo" that receives all events again
3. later kill that transient subscription and start the persistent subscription "foo" again, this will now just resume after the lasted acked events that the persistent subscription "foo" saw.

I think this is logical, but it might surprise some users, so I'll add it to the documentation.

[tcoopman]

I'm not sure why this PR also includes e9e9492. I thought I started from master correctly.

[slashdotdash]

Yes, it looks like you are on the right track.

[tcoopman]

@slashdotdash I think the functionality is complete, so ready for review.

[slashdotdash]

Thanks @tcoopman, sorry for the delay in merging your PR.