protect against slot invalidation from max_slot_wal_keep_size

[psteinroe]

this is an unlikely event, but can happen if the sink is very slow in accepting requests and the batch size is small while event throughout very high.

if we would control the etl, we could persist the latest successful event, re-create the replication slot and replay events. I would rather not fork though, especially not for an unlikely scenario such as this one.

we could add safe-guards though to make sure this never happens:

• introduce a timeout for the sink request and enter failover if the timeout is hit
• track the wal backlog size and enter failover if we reach a certain limit
• if we are in failover and the wal backlog is too high, dont even try to send the events to the sink

this will make it almost impossible for the replication slot to be invalidated.