#### Summary of Changes
Removes the constant default for ShredStorageType::RocksFifo
as the shred storage size is either user-specified or derived
from --limit-ledger-size in #27459.
* Add new empty crates and tpu_connection_cache module
* Add BaseTpuConnection trait and impl for udp and quic
* Add ConnectionPool trait and impl for udp and quic (quic-client doesn't build)
* Add a couple quic-specific apis to QuicConfig (from ConnectionCache)
* Re-export quic- and udp-client modules to prep for move
* Move ConnectionCacheStats to new module
* Move consts
* Duplicate ConnectionCache into tpu_connection_cache (doesn't build)
* Move methods to QuicConfig and remove unneeded methods (doesn't build)
* Genericize new ConnectionCache
* Rename new struct
* Copy unit tests (tests don't build)
* Fixup unit tests
* Move quic-specific test to quic-client crate
* DRY by using ConnectionPool method
* Prevent evicting pool about to be used
- Batch filtering invalid transactions (fail to sanitize, too old or already processed) before forwarding
- Combine packet filtering and forwarding to share sanitized transactions
- `iter_desc` is no longer needed, remove it;
- Add a method to share the logic of removing packets from buffer after they were removed from MinMaxHeap
- Add test coverage for forward_packet_batches_by_accounts
- rebase, resolve conflicts
### Problem
When FIFO compaction is used while --rocksdb_fifo_shred_storage_size
is unspecified, the FIFO shred storage size is set to a const default based
on the default `--limit-ledger-size`.
### Summary of the Change
When --rocksdb_fifo_shred_storage_size is unspecified, it is now
derived from `--limit-ledger-size` by reserving 1500 bytes for each
shred.
Currently, gossip packets are counted after excess packets are dropped.
This makes it difficult to debug gossip traffic spikes if the majority
of the packets are dropped.
This commit instead counts gossip packets received before excess packets
are dropped
### Problem
The documentation of each column family is missing
### Summary
The goal is to create a comment block that will essentially include a high-level
concept on what each column family is about and what are their key/value formats.
This PR is the first cut that includes the key/value format of each column family.
This should at least provide an easy pointer for readers to understand what this
column family stores by searching its value type and how to access the data based
on the key type.