Ed25519 signature usage prone to inconsistent peer views between LibP2p implementations

Ed25519 signatures are defined in the spec as per the RFC: https://github.com/libp2p/specs/blob/87c684e2451684445e8ae8073c90add9645b3b26/peer-ids/peer-ids.md?plain=1#L166

Unfortunately, the RFC is incomplete with regards to edge cases. Please see https://hdevalence.ca/blog/2020-10-04-its-25519am for more info.

While additional rules have been created (ZIP-0215, further adopted by IOTA), and implemented into a variety of libraries becoming the defacto standard (ed25519consensus, ed25519-zebra), they are not employed by LibP2p.

To reduce the risk of some peers finding some peers valid which others do not, LibP2p should explicitly standardize its signature rules to ZIP-0215 or an equivalent spec.

Please note this an active possibility. rust-libp2p uses curve25519-dalek's verify (banning torsioned Rs, distinct from clearing their cofactor) and depending on the features used, may accept some unreduced s values (which rust-libp2p cannot prevent due to the way features work in Rust). go-libp2p uses Go's crypto/ed25519 bans torsioned Rs and doesn't accept unreduced s values. js-libp2p does already use ZIP-215 rules as a side effect of it being the default for Noble.

Start with the linked libp2p peer-IDs specification and ZIP-0215, then compare the Ed25519 behavior described for rust-libp2p, go-libp2p, and js-libp2p. Done means the libp2p specification explicitly defines consistent signature-validation rules, using ZIP-0215 or an equivalent standard.