feat(Ed25519-Key): Improve validation speeds in browsers

[Chandelier-02]

Title

feat(Ed25519-Key): Improve validation speeds in browsers

Description

In this PR, I've replaced most Ed25519 key operations with Web Crypto alternatives. With many browsers soon rolling out full support for the Ed25519 key type, this is an opportune time to integrate the new API into Libp2p. The primary benefit is the significant performance improvement that WebCrypto offers.

Simple benchmarks show substantially higher throughput compared to the @noble/curves library implementation of the Ed25519 key.

I've also tested the performance difference in one of my projects that receives numerous messages over gossipsub (verified via Ed25519). The results show a dramatic reduction in main thread usage during high message rates, especially with large messages.

Notes & open questions

I could not figure out how to derive a Ed25519 public key from a private key (don't think it's supported in the WebCrypto API), so I am utilizing the Noble Curves library to handle that. Not certain of the security implications of this.

Since Ed25519 key support is currently behind experimental flags in Chromium browsers, I've implemented fallback detection that reverts to the previous Noble curves implementation when the API is unavailable.

There are two tests in the random walk test file that I haven't been able to resolve due to timing conditions: 'should continue random walk until all consumers satisfied' and 'should not block walk on slow consumers'. All other tests are passing.

Change checklist

• [ x] I have performed a self-review of my own code
• I have made corresponding changes to the documentation if necessary (this includes comments as well)
• I have added tests that prove my fix is effective or that my feature works

[Chandelier-02]

I have spent some time looking into the reason for why those two specific tests are failing in the 'random-walk.spec.ts' file. The specific test that's failing is this one:

it('should continue random walk until all consumers satisfied', async () => {
    let yielded = 0

    peerRouting.getClosestPeers
      .onFirstCall().callsFake(async function * (key, options?: AbortOptions) {
        for (let i = 0; i < 100; i++) {
          options?.signal?.throwIfAborted()
          yielded++
          yield await createRandomPeerInfo()
        }
      })
      .onSecondCall().returns(slowIterator())

    await Promise.all([
      drain(take(randomWalk.walk(), 1)),
      drain(take(randomWalk.walk(), 2))
    ])

    expect(yielded).to.equal(3)
  })

After adding a bunch of logging in the random-walk file, I do see that each consumer is getting satisfied, but the yield is only occurring twice.

First, PeerInfo-A gets generated, and both consumers see it. The first consumer is then finished as it saw its one peer it wanted. Then, PeerInfo-B gets generated. The second consumer is then finished.

When comparing the old PeerId implementation vs the new one in this PR, the only difference I see that would change test behavior is that the new PR's PeerIds get generated much faster. So, I am thinking there is a race condition in the test. Maybe the test is trying to gauge the wrong metric (number of peer infos yielded vs satisfied consumers).

Maybe I am misunderstanding what this test is trying to do.