Fix flush race

[agouin]

Without this, acks are not being cleared fully from the caches when giving up on sending a packet message after max retries.

I think this is caused by a race condition with flushing. Flushing performs queries and enqueues chantypes.EventTypeSendPacket or [chantypes.EventTypeRecvPacket, chantypes.EventTypeWriteAck] events when recvs or acks need to be relayed, respectively. These can be enqueued after the respective action was already successful and observed, which I believe is causing the looping ACKs.

Some potential ways to handle this:

• maintain separate cache (or build into existing PacketSequenceCache) of state for a sequence number where sequences expire after some amount of time. Then, when flushing, check if the sequence is already beyond the state that is about to be enqueued. If so, don't enqueue it.
• clear caches of a sequence when an ACK that we have broadcasted is successful (since we will not get another acknowledge_packet event for the uneffected acks, which is currently necessary to clear the caches)
• pause cosmoschainprocessors when performing flush (not desirable as it will slow down relay performance)

Resolves #1359

[jtieri]

after our discussion in Slack I think I have my head completely wrapped around the changes here! everything looks good, only thing i can think of is that we may possibly want to make the value passed into Prune configurable at some point but not necessary rn