feat: add static http gateway routing

[achingbrain]

Adds a routing implementation that returns a static list of gateways as providers for CIDs.

It's expected that these gateways are able to fetch content on our behalf.

Depends on:

• feat: extensible peer ids libp2p/js-libp2p#2496
• fix: do not append peer ids to provider multiaddrs #516

Change checklist

• 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

[2color]

Does it make sense to use the code for transport-ipfs-gateway-http instead?

Suggested change

	const LIBP2P_KEY_CODE = 0x72
	const TRANSPORT_IPFS_GATEWAY_HTTP_CODE = 0x0920

[achingbrain]

Sure, I have no strong preference here, really it just needs to be unique to allow comparison between peer identifiers.

Reading the PR that added that code the intention was for numbers to be used instead of peer protocol strings so I don't think there'll be any collision?

[2color]

I'm curious, how do you plan on using the HTTPGatwayRouter once merged?

[achingbrain]

how do you plan on using the HTTPGatwayRouter once merged?

It'll be configured like any other router and will let http gateway sessions fall back to a default set of gateways.

We'll also be able to switch the gateway block broker over to use the helia routing which will let it find non-preconfigured gateways but also fall back to the default ones.

[SgtPooki]

looks straightforward to me but i'm not intimately familiar with PeerId class we're implementing.

i think sync multihash is fine, toCID should be unique per URL.. ship it

[SgtPooki]

I'm curious, how do you plan on using the HTTPGatwayRouter once merged?

Some context for @2color from chat I had with @achingbrain when talking about issues with trustless-gateways related to testing out the changes in ipfs/helia-verified-fetch#50

Basically I’m not sure we’re ready for HTTP Gateway sessions yet.
To that end I’ve put this PR together that adds a routing implementation that just returns a static list of gateways - #515
This way when we get better HTTP results via the delegated lookup in the future we can just turn off the static list.

Essentially, we need some way to reduce the breadth of content-fetching requests (via sessions), and trustless gateways returned from delegated routing providers are not consistently reliable and frequently not available at all.

When I was looking into it, I proposed having trustless gateway sessions fall back to the provided trustless-gateways passed to blockBrokers. IIUC, this PR enables a version of that fallback in the defined "routing" language we've recently moved to in helia.

Alex to correct me here if I'm wrong or too imprecise.

[achingbrain]

That's it, all good.

[2color]

Nice! Cool stuff