[cleanup] Remove fastutil dependency

[merlimat]

Summary

• Replace fastutil collections with minimal open-addressing hash map/set implementations in pulsar-common using the same approach (primitive keys, Fibonacci hashing, backward-shift deletion)
• Replace fastutil pair types (IntIntPair, ObjectIntPair) with Java records
• Use java.util.TreeMap directly for sorted maps instead of fastutil's Long2ObjectAVLTreeMap/Long2ObjectRBTreeMap
• Remove the pulsar-client-dependencies-minimized module and all fastutil shading/relocation configuration

New classes in org.apache.pulsar.common.util.collections:

• Long2ObjectOpenHashMap, Long2IntOpenHashMap, Int2ObjectOpenHashMap
• LongOpenHashSet, IntOpenHashSet
• IntIntPair, ObjectIntPair (records)
• Long2ObjectMap, Long2IntMap (interfaces)
• LongObjConsumer (functional interface)

Migrated 7 files across pulsar-broker and pulsar-client:

• DrainingHashesTracker, PersistentStickyKeyDispatcherMultipleConsumers
• Consumer, InMemoryRedeliveryTracker, PendingAcksMap
• InMemoryDelayedDeliveryTracker, NegativeAcksTracker

Motivation

Fastutil is a ~21MB jar but Pulsar only uses a handful of its classes (maps, sets, and pairs) in 7 files. The custom implementations are minimal, only covering the operations actually used, and follow the same open-addressing design to preserve performance characteristics.

Why open-addressing hash maps instead of java.util.HashMap

Open-addressing with primitive key arrays (long[], int[]) avoids boxing keys to Long/Integer and avoids allocating Entry objects entirely. A map with N entries has zero object overhead beyond the flat arrays — this is a meaningful saving over HashMap which allocates an Entry node per key-value pair plus boxes every primitive key.

Why TreeMap instead of fastutil's Long2ObjectAVLTreeMap/Long2ObjectRBTreeMap

Unlike open-addressing hash maps, tree maps inherently allocate a node object per entry to maintain the tree structure. Since each entry already requires a node object, avoiding the long → Long boxing of the key saves only 16 bytes per node — a negligible overhead on top of the node object itself. java.util.TreeMap provides the same algorithmic guarantees (red-black tree, O(log n) operations, sorted iteration, headMap/tailMap views) with no practical performance difference, so there is no reason to carry a custom implementation.

Documentation

• doc-not-needed

Matching PR in forked repository

No

Test plan

• Unit tests added for all new collection classes (Long2ObjectOpenHashMapTest, Long2IntOpenHashMapTest, Int2ObjectOpenHashMapTest, HashSetTest)
• Verify existing broker and client tests pass with the new implementations
• ready-to-test