pubsub: fix a subtle race in catch up logic for barely active subs

[pborzenkov]

The order of events processing when Corrosion is handling a change is:

• determine changes
• send changes to the channel
• commit changes to sub DB

When Corrosion client is catching up it subscribes to changes sent to
the channel and queries the full sub DB. It's possibly that the query
is run before the changes are committed, but after they've been sent
to the channel, so what happens is:

• A change with ID N is processed by Corrosion and sent to the channel
• catch up logic starts and subscribes to changes, but doesn't see
  this change
• sub DB is read and sent to the client, last committed change ID is
  N - 1, so EndOfQuery{change_id: N - 1} is sent to the client
• corrosion commits the last update so the last change in the DB becomes
  N
• catch up handler has min_change_id = N - 1 + 1, so when it compares
  last sent change ID (N) with min_change_id (N) it ignores it becase
  the comparison is strictly greater.

min_change_id is what we expect to receive, so the fix is trivial -
comparison should be greater or equal.