Rev-up and snapshot from best responder

[gsvarovsky]

Note: this applies to "pubsub"-style remotes, which at present is all of them: MQTT, Ably & socket.io. The remotes concept in general can do whatever it likes.

Rather than sending requests to clones in arbitrary order, recovery could publish its request and only ack the fastest response (sending 'abort' to any others).

• + simple optimisation for latency
• + does not require complex/brittle channel presence (possibly doesn't work well in a split-brain, Split-brain handling #29)
• - requires an extra round of conversation, to minimise open transactions, because a responder currently opens a transaction when responding successfully
• + saves on presence messages (probably broadcast) but
• - multiplies recovery messages (broadcast)

In addition to latency, a collaborator may have better or worse response efficiency due to:

• platform limitations (e.g. favour servers)
• journal optimisations (favour compressed)