STICKY_POLLING optimizations for the cloud

Current behavior for STICKY_POLLING configuration, for both the bus and notification queue, is to only look at entries in the database that match the Creator name of the current node. The issue is when a node goes away: currently, a manual update of the database entries is required (see https://github.com/killbill/killbill/wiki/Kill-Bill-Bus-and-Notification-Queue-Configuration).

Instead, we would now have a new Reaper thread that periodically monitors such entries and re-dispatch them automatically. To detect such entries, we need to look for bus events with an old created date or notification events with an effective date too far in the past (actual thresholds configurable, 5' by default). Such detection is already done today in the queries (see second part of the where clause in

killbill-commons/queue/src/main/resources/org/killbill/bus/dao/PersistentBusSqlDao.sql.stg

Line 14 in 624a819

and (processing_owner IS NULL OR processing_available_date \<= :now)

and

killbill-commons/queue/src/main/resources/org/killbill/notificationq/dao/NotificationSqlDao.sql.stg

Line 21 in 624a819

and (processing_owner IS NULL OR processing_available_date \<= :now)

), we would need to introduce similar queries but focusing only on such old entries. These entries would then be updated to reflect the current Creator name (maybe re-dispatch 10 at a time, configurable).

Additional tests to write in TestDBBackedQueue.