[#4829] Do not decide gap recording from an event's message timestamp

[schananas]

Fixes #4829
Fixes #4834

What changed

Gap recording no longer consults an event's message timestamp. A global index is taken from a database sequence before the transaction commits, so a reader routinely sees index n+1 while n is a hole that fills later. The reader decided whether to remember that hole by comparing the visible event's own message timestamp against its wall clock, and recorded no gap when that event looked older than gapTimeout. A message timestamp is set in the handler, always before the commit, and the interval between the two is unbounded, so the shortcut could only ever fire too eagerly. Worse, the stale path called advanceTo(index, 0), which discards already-recorded gaps rather than merely declining new ones: token(102,{101}) plus row 105 yields {101,103,104} now and {} before.

Holes are always recorded now, bounded by maxGapOffset, which becomes the single give-up point. gapTimeout goes back to meaning the gap-cleaning knob its Javadoc always described.

terminate() no longer hangs (#4834). It blocked on an unbounded pollingThread.join(), so it wedged whenever the polling thread could not reach the top of the loop -- including simply being parked inside countEvents()'s JDBC call. The join now has a 5-second deadline and warns if the thread has not stopped; the loop also stops on its terminated flag rather than only on the interrupt.

maxGapOffset = 0 is rejected. It was accepted and silently restored the old behaviour.

Tests

AggregateBasedJpaEventStorageEngineIT#streamDeliversAnEventCommittedIntoAHoleUnderAnEventOlderThanTheGapTimeout is red on unmodified main (ConditionTimeoutException, the reader never returns the filled index) and green here. It runs on HSQLDB, no container. The hole is made by skipping the global-index sequence, which is what an uncommitted append leaves behind.

It replaces gapsForVeryOldEventsAreNotIncluded, which asserted the removed behaviour and tested nothing: its DELETE ... WHERE aggregateSequenceNumber < 0 matched NULL for tagless events, so it deleted no rows and streamed a contiguous store. Its own tokens.size() == 8 expectation after supposedly deleting 4 of 8 rows is the tell.

JpaPollingEventCoordinatorTest covers both terminate() paths; the blocked-poll case is 3 of 3 red with the join unbounded.

For the reviewer

No reader-only fix can be fully sound. From committed rows alone a hole is indistinguishable between abandoned and held by a slow transaction. maxGapOffset is a bounded mitigation, not a proof. A real proof needs the store's transaction state, on PostgreSQL the xmin low watermark, which is not expressible in portable JPQL.

This makes the surviving unsound comparison in withGapsCleaned more reachable, not less. At a 10% hole rate over 400 batches, main crosses gapCleaningThreshold (250) on 0 of 400 batches; this branch on 375 of 400, peaking at 940 gaps.

The real bound on Spring Boot is 60000, not 10000, because of the swapped defaults in #4799. That is an 88 KB token at 10000 gaps and 527 KB at 60000, written every batch, and a 60000-element IN list exceeds Oracle's ORA-01795 limit of 1000. Replay is affected too: every historical hole now becomes a gap.

Related: #2958 is a closed 4.9.1 production report of a processor wedged with gaps [[]] whose workaround admits "possibly losing processing of the gap events". Same code path.