Support pending writes within CachedCounterValue

[alexsnaps]

Alright, this is a shot at unifying the "write-behind" and the cache we use in front of Redis.
It does so in a few ways:

• The "pending increments" are recorded directly in the CachedCounterValue
• Both the cache and the "write-behind queue" (still a Map) point to the same instance of a CachedCounterValue (within an Arc) for the same Counter "key"
• All entries added to the Cache should be atomic and only then added to the Batcher (our write-behind "queue")
• We always look up in the Batcher if a CachedCounterValue is mapped to key, in case it got evicted from the cache
• We only add CachedCounterValue to the Batcher with an .pending_writes() > 0
• We only remove atomically from the Batched if the .pending_writes() == 0
• If we ever added two different CachedCounterValue instances (there is a race when inserting into the cache and being evicted before we made it into the Batcher, where we then merge the pending writes from one CachedCounterValue into the other one

This was achieved by doing:

• folding the pending writes within the CachedCounterValue
• change the CachedRedisStorage.batcher_counter_updates to point to the same Arc as within CountersCache.cache
• use the CachedCounterValue to populate the batch to redis (and update the values back)
• Introduce a proper Batcher type back exposing .add() and .consume(u64).await
• Have the Batcher awaken on either: flush period being elapsed the batch size being reached
• Flush on "important" flushes being required
• .consume would return the most "important" updates first always
• Lookup the queue on cache misses
• Address Use 0 as a default on CachedRedisStorage cache misses #298

This still misses tests 🤦 yet I still think this is better than what we had before... So, I think we should merge this and iterate, but only if my reasoning makes sense and "seems to be implemented" in this PR.

[alexsnaps]

If after having flushed to redis no additional pending writes were added, we can remove these entries from the queue.

[chirino]

if we start constraining the batch size sent to Redis, we may want to add the priority flag in the value too so that the first batch we execute contains the priority items first.

[alexsnaps]

Yeah, I do this "hack" where I check the TTL on entry… to decide the things that are "important", but I think I should maybe just waste the additional bit… 

[didierofrivia]

DashMap makes it much cleaner and easier to consume <3

[didierofrivia]

The part that I particularly find hard/complex is the consume method, that first iterates to get the hot counters that needs to flush asap, but then we iterate again to find a remainder and push it to the same batch (?), then we need to iterate again to have the final batch that we will send to the batch update fn. I only wonder if it's possible to simplify the collection we send to update... maybe in the near future we can review this. Great work! 👍🏼