feat: allow setting Kad K_VALUE using feat flag

[mickvandijke]

Description

Introduces new feature flags to change the K_VALUE for Kademlia. The new feat flags are: k-4, k-8, k-12 and k-16.

Related issues:

• Kademlia: custom K_VALUE #5875
• Why rust-libp2p kademlia protocol's K_VALUE is consistent #5501

Notes & open questions

I know that Config::set_kbucket_size is a thing, but that doesn't change the K_VALUE, which influences many parts of the code.

I have tried making the K_VALUE configurable using a compile time environment variable and a build script, which would arguably be a cleaner solution, but I couldn't get it to work.

So I thought using feat flags would be a nice, although maybe a bit unorthodox alternative, that doesn't require significant code refactoring.

Change checklist

• I have performed a self-review of my own code
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• A changelog entry has been made in the appropriate crates

[mickvandijke]

Amended the commit to mutex all k-n features and default to K = 20 if all features are enabled.

[mickvandijke]

Updated the CI to run the libp2p-kad tests with all the k-n features separately.

[elenaf9]

Hi @mickvandijke, thank you for your PR!

Citing @guillaumemichel from #5501 (comment):

On a note, this magic K_VALU E is having 3 different roles, that could be decoupled from each other:

1. Size of the routing table's buckets
2. Number of replications of provider records when they are published
3. Number of closer peers that are returned during a kademlia lookup

#5414 enables to set a custom bucket size without updating the other parameters. Unless there is a need to tweak the other 2 parameters, we should stick with using a single K_VALUE for all 3 parameters and users can set a custom bucket size if required once #5414 is merged.

Can you expand a little bit on why you need to modify 2) or 3)?

---

Implementation wise @guillaumemichel is probably best to review this, but I don't think we should use feature-flags.

1. They only allow a fixed list of possible K_VALUES. If we support custom K_VALUE IMO we should support all non-zero ints
2. Features in Rust should be additive, which is not the case with these new features. E.g. enabling both k-4 and k-8 will cause a conflict.

Two alternative solutions that came to my mind:

• Make it a Config option. We'd then have to change a few types from K_VALUE-length arrays into Vecs
• Make it a const generic on Behavior and other affected types, that defaults to 20. Not sure how many types this would affect.

[guillaumemichel]

I agree with @elenaf9, feature flags are probably not the correct way to add configurability for K_VALUE.

Two alternative solutions that came to my mind:

• Make it a Config option. We'd then have to change a few types from K_VALUE-length arrays into Vecs
• Make it a const generic on Behavior and other affected types, that defaults to 20. Not sure how many types this would affect.

Both suggested solutions seem like a better way to proceed.