migrate bootstrapper away from RSA

### Checklist

- [X] My issue is specific & actionable.
- [X] I am not suggesting a protocol enhancement.
- [X] I have searched on the [issue tracker](https://github.com/ipfs/kubo/issues?q=is%3Aissue) for my issue.

### Description

After benchmarking libp2p handshakes, it turns out that _verifying_ signatures is roughly equally fast for RSA and for Ed25519 keys. Where performance differs significantly is while _signing_. For CPU performance, it therefore doesn't really matter which key type your peer uses, it only matter which key type you use.

The conclusion can be summarized: If you care about your CPU load, you really don't want to use an RSA host key.
This is why generating Ed25519 on `ipfs init` makes sense, and adding a warning to nudge people to migrate away from RSA (https://github.com/ipfs/kubo/pull/9506) does too.

## libp2p planning to drop OpenSSL support

OpenSSL can be used to speed up RSA operations. There's some numbers in https://github.com/libp2p/go-libp2p/pull/1686#issuecomment-1219412636, due to a bug (https://github.com/libp2p/go-libp2p/issues/1951) only the number for signing are valid.

While OpenSSL helps bring down the cost of RSA signing from 1.2ms to 0.5ms, it is still _vastly_ more expensive than Ed25519 signing, which sits at around 22µs.

libp2p is planning to drop OpenSSL support soon (https://github.com/libp2p/go-libp2p/issues/1952), since it has been creating a disproportionate amount of maintenance burden with unclear benefit. As argued above, the only benefit is that it provides is slightly reducing the amount of self-inflicted pain from using RSA keys.

## Bootstrappers

The only problem with this advice ("just don't use RSA keys) is that Kubo has hardcoded peer IDs of bootstrappers, and those still use RSA keys for historic reasons. As the IPFS network is notoriously slow to upgrade to new Kubo versions, at least some of these nodes will probably need to keep running for years. As libp2p is dropping OpenSSL support, this means that these bootstrappers would not be able to update to Kubo versions that use those newer go-libp2p versions.

This problem does not occur with Hydra nodes, as those don't use hard-coded peer IDs (as far as I can tell), which should make it trivial to switch them to Ed25519, in case they were deployed with RSA.

Assuming that handshakes are a significant component of the CPU load of bootstrappers , significant savings of CPU time can be expected from switching them to Ed25519.
I don't have access to them, but it should be easy to confirm or disprove by getting a pprof. I took some pprofs from a Kubo node that I set up which runs the Accelerated DHT client, and it looks like other code paths are still more expensive, but that might not translate well to what the bootstrappers are doing.
It might be interesting to convert these CPU savings into $$$ by scaling down the hardware these nodes run on.

I'm opening this issue to explore a transition path to use a new set of bootstrap nodes that posses Ed25519 keys. One option I can think of would be to locate them on a new subdomain. We need to pay attention to keeping the DNS message size small due to https://github.com/libp2p/go-libp2p/issues/1837.
Arguably, IPFS bootstrappers should live on `bootstrap.ipfs.io`, not `bootstrap.libp2p.io`. New versions of Kubo would then (exclusively?) ship the list of new bootstrap nodes, which would reduce the load on the old bootstrappers as nodes upgrade. This would allow us to gradually scale down the hardware they run on, and decommission them eventually, probably after a few years.