Open
Description
Describe the bug
When a sender is denied, it aggregates too slow since rav requests are only triggered by UpdateReceiptFees
message.
Those messages are only sent when the rav request finishes or after retry_interval
(~30 secs).
This makes the aggregation process too slow in cases where the aggregator is UP. Our logic currently treats that the aggregator is down but what might have happened is that tap-agent was down for a while and now the sender is denied.
Solution
We should use the backoff_information to retry aggregating instead of a fixed retry_interval.