send queue: avoid losing local echoes when sent but not remote-echoed

[bnjbvr]

When sending an event with the send queue:

• while it's being sent, it's still in the queue, and will appear as a local echo
• just after it's been sent (response to /send), it's removed from the queue

The event might have not come back from the sync as a remote echo, so there's a tiny period where the "local echo" has been sent (hence it's removed from the send queue) but not present from the sync (so missing there too). That makes it look like the event "disappeared" for a short while, especially if your /send was fast, but your /sync is slow (which explains why I could never reproduce it).

To fix this, the send queue would have to listen to sync, and only remove from the send queue when an event has been remote-echoed, right? No, it's not sufficient: what if your device has been off for a long time, then you'll never receive the remote echo, unless you also listen to back-pagination etc. events (from the event cache?).

It's getting a bit tricky, and likely doesn't occur if your sync is fast. @poljar suggested a nice compromise:

• listen to sync in real-time, and remove local echoes from the queue as they show up in sync
• when restarting the app, vacuum all sent local echoes, assuming they'll either appear soon-ish, or they've already appeared in previous syncs

This might require a migration, because the send queue stored events don't contain a send state. We might as well repurpose is_wedged into something more generic, and store the error messages to help with other crypto requirements.