Return to a one-token-per-channel model

[jchambers]

This essentially reverts #850 (though a direct revert wasn't practical given the volume of changes between #850 and the present). We've observed in #931 that a shared token model can lead to a situation where:

1. Channel A is opened and prompts generation of a new authentication token.
2. Time passes.
3. Channel B is opened shortly before the original authentication token is expired.
4. Channel B sends a message with the original authentication token.
5. Time passes.
6. The original authentication token expires and a new one is generated.
7. Channel B sends a message with the new authentication token.

In that case, from the server's perspective, channel B has used two different authentication tokens in rapid succession, leading to a TooManyProviderTokenUpdates rejection.

The hope is that this fixes #931. At the same time, this will need some testing because this is reverting to exactly(?) the same state that prompted us to try #850 in the first place.

[kicktipp]

It still works fine after over a week of sending lots and lots of messages. Can you make a release?

[jchambers]

Thank you for the update. I plan to issue a new release soon, but it's a process more limited by Real Life Stuff than any technical concern at this point.