Improve storage of PendingPackets on consumer

[shaspitz]

Problem

The consumer ccv module currently queues "pending packets" to be sent on each endblocker in SendPackets. These packets are queued using a protobuf list in ConsumerPacketData. For a single append operation, the entire list is deserialized, then a packet is appended to that list, and the list is serialized again, See AppendPendingPacket. That is, a single append operation has O(N) complexity, where N is the size of the list. This isn't a problem when the list is small. But with #713 being implemented, this list can potentially grow to the order of thousands of entries, in the scenario that a slash packet is bouncing.

Proposed solution

We can improve the append time for this queue by converting it from a protobuf-esq list, to a queue implemented with sdk-esq code.

My rough idea: The key schema for storing slash and VSC matured packets will look like [prefix]-[blockheight] and the value for each key will contain a protobuf list with any packets queued for that blockheight. Since we're keying by blockheight, an sdk iterator will iterate over the keys in FIFO order. That's it. We'll have to append to a protobuf list, but only for multiple packets that're queued during the same blockheight. Otherwise if most packets are queued from different block heights (which is surely the case for VSCMatured packets), appending to the queue is near constant time.

Note this should be solved in it's own PR separate from other throttle related changes

[shaspitz]

cc @jtremback since we chatted about this

[shaspitz]

Actually theres an even simpler way to approach this problem.

Store a head/tail integer for the pending packets queue. Whenever you append to the queue, simply store the new entry with key looking like: [prefix-tail+1]. Then Increment tail.

For access, leverage sdk's iterator, keys are already ordered by ascending bytes.

Maybe there's already some queue boilerplate in sdk? I'll take a look on Monday