add bootstrap config for LAN DHT

[BigLep]

With the next go-libp2p release it is gonna be smarter and sequence dials by how usefull they are meant to be.
This means if LAN addresses are found it will sequence thoses first. Right now we publish all addresses to all DHT, so LAN addresses can be found on the WAN DHT slowing down this new more efficient dialler, to fix this go-libp2p-kad-dht is gonna only publish relevent addresses to the relevent DHTs (see libp2p/go-libp2p-kad-dht#839).
Some peoples run IPFS cluster on Virtual Private Clouds, this is a network in LAN space which all of your machine goes. Some cloud platform that tries to vendor lock in users do not count IP transit cost if traffic goes through this network instead of the exact same traffic going over the public IPs of the VMs. Right now running multiple IPFS nodes inside the same VPC will have the machines announce their local VPC addresses on the public DHT, so they can find each other in the VPC, saving on cost and having higher performance between all of thoses nodes, if we stop having private IPs on the public DHT supported this means they will need to rely on the LAN DHT instead, which isn't working on theses network right now due to the impossibility of using MDNS for bootstrap (no multicast).

We should add a LANBootstrap list, or make this configurable per router, so users in the thoses networks can setup their own LAN dht, as well as guide users who uses LAN networks without multicast to these options.

Suggestion is to have a bootstrap list per router.

[BigLep]

2023-07-06 maintainer convesation: we agree this is good/reasonable todo. That said, we are ok to ship a go-libp2p update without this as things will "still work" :)

[Jorropo]

We agreed to release without this to unblock 0.22, as a workaround you can put your LAN dht bootstraps in the WAN's dht bootstrap and due to multiple layers of callbacks and events it works out.
This is not a great workflow so we would want to fix this, not have this workaround become permanent.