feat(kad_dht): implement grid topology with 256-bucket Kademlia DHT

[asmit27rai]

This PR implements a complete Grid Topology for the Kademlia DHT routing
table in py-libp2p, following the cpp-libp2p specification. The implementation
provides a fixed 256-bucket binary tree structure organized by XOR distance
metrics for efficient peer discovery and management in distributed networks.

Fixes: ##1293

[asmit27rai]

@seetadev Please have a look and share your feedback.
Thanks.

[seetadev]

@asmit27rai : Neat progress. Please resolve the CI/CD issues.

CCing @sumanjeet0012 on the thread.

[sumanjeet0012]

@asmit27rai,

• please create an issue for this PR outlining the rationale behind introducing a grid topology with a 256-bucket Kademlia DHT.
• Clarify whether this approach is intended to replace the existing k-bucket implementation.
• Alternatively, specify if it should remain optional, allowing users to choose between different k-bucket strategies.
• Once the issue is created, please add a newsfragment file as well.

[asmit27rai]

@sumanjeet0012

1. No, Grid topology is optional and complementary. Both implementations coexist and allowing users to choose based on their requirement. No breaking changes.
2. Users choose which k-bucket strategy to use. No replacement. Both available.

[sumanjeet0012]

@asmit27rai, could you please provide an example file demonstrating how to run the Kademlia DHT with a grid routing table? This will help us test it by executing the example.

[sumanjeet0012]

Examples should be placed in https://github.com/libp2p/py-libp2p/tree/main/examples/kademlia

[sumanjeet0012]

Why the max_connections_num ( configuration related to advanced connection management ) present here.

[sumanjeet0012]

This is related to pubsub, what's the use of floodsub_forward_mode here ?

[sumanjeet0012]

We are not using most of the configurations in our project. Should we simplify and clean up the configuration by keeping only the entries that are actually in use?

[asmit27rai]

@sumanjeet0012 Addressed your review.

[sumanjeet0012]

@asmit27rai

Implementing a grid-topology routing table for the Kademlia DHT is a valuable contribution and has the potential to improve the routing layer. However, after reviewing the current implementation, I identified several significant issues with the proposed grid-topology k-bucket design that should be addressed before it can be considered for merging.

The issues are:

1. No Integration With the Existing DHT
   The GridRoutingTable is a completely standalone class that does not implement any interface from the existing code. It doesn't implement the RoutingTable protocol used by KadDHT. Looking at routing_table.py, the existing RoutingTable uses:

• IHost for network operations
• trio for async operations
• KBucket with splitting logic
• add_peer(), remove_peer(), find_closest_peers() etc.
  The GridRoutingTable has none of this. It's a disconnected data structure that cannot actually be used by KadDHT without major refactoring.

2. Duplicate Code
   The NodeId class reimplements XOR distance and common prefix length, which already exist in routing_table.py (peer_id_to_key, key_to_int) and utils.py (xor_distance). The GridBucket class reimplements k-bucket logic that already exists in KBucket.

3. No Async Support
   The existing RoutingTable is async (uses trio). The GridRoutingTable is entirely synchronous. This means it can't integrate with the existing async DHT operations.

@asmit27rai Once you address these issues, Kindly create an example which uses the new routing table and try to demonstrate the working of the same using the public APIs of Kademlia DHT.

[asmit27rai]

@sumanjeet0012 Addressed the comment.