v2.7.1404

chore: separate feed executors

The event feed was being serviced by one executor that fired every 250ms and
cycled through all feeds to output any new events. There was a chance (however
small) that if one feed hung then events wouldn't get to the next feed for a while.
Or more likely: a new client over a slow connection getting the entire feed causes
an existing client to wait a second to get the next event.

This completely revamps each event-feed to be independent. When there are events
it schedules an output job; when there aren't a future heartbeat is scheduled.

Net:
- Multiple events in short succession (e.g. during startup) are still batched.
- When there are events, they're independently run on different executors instead
  of one by one: a burst of jobs for each feed client, but each is very small and
  short lived.
- No more checks every 250ms, even if there have been no events. No events = only
  future heartbeat job scheduled.
- If the access policy means a client will never see an event it is now immediately
  ignored.

One more change: for reconnection, instead of reading from the start throwing out
the first 'num' events, it now starts at that index directly from the contest
data. Slightly more efficient, and makes the ContestObjectQueue a little simpler.

Fixes #1352.