feat: support provider query parameter

[vasco-santos]

Add support for provider query parameter

Description

This PR propagates provider from query parameters as described in https://github.com/vasco-santos/provider-hinted-uri/blob/main/EXPLORATION.md#-uri-design to be used as Hints by Helia's blockBrokers.

Regarding changes, it simply changes parseUrlString util function to verify if valid multiaddrs are in the query parameters and also returns them. They are then simply propagated to the options parameter that makes its way to the plugins pipeline, where a broker session is created and is used.

These feature is currently behind a feature flag while it is in experimental stage (allowProviderParameter)

const url = `ipfs://${cid}?${query}`
const resp = await verifiedFetch.fetch(url, {
  allowProviderParameter: true
})

Notes & open questions

Currently does not embed proto in the multiaddrs (for instance /retrieval/bitswap/retrieval/http). We will as follow up discuss how to support something along these lines.

@achingbrain while this is more experimental, opted to not add example in Readme. Should I add though?

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

[vasco-santos]

eslint complains there is too many nested callbacks 😬

[lidel]

Since this will impact verified-fetch and inbrowser.link, are you planning to open IPIP about ?provider in https://github.com/ipfs/specs/pulls?

I would softly block on having a spec PR that we can comment on :)

FYI the usual path towards extending Gateway interface (implemented by verfified-fetch) is to follow light IPIP process:

1. Open PR with IPIP memo in https://github.com/ipfs/specs/ that describes rationale for new feature:
   • older example: IPIP-402: Partial CAR Support on Trustless Gateways specs#402
   • recent example: IPIP-484: Opt-in Filtering on Routing V1 HTTP API specs#484
   • This does not have to be perfect, CI does not need to be gree, for now just open a Draft PR that documents the new parameter and syntax of accepted values so we have place to comment and discuss. Fine to copy your existing content from https://github.com/vasco-santos/provider-hinted-uri/blob/main/EXPLORATION.md#query-parameter-provider (the ?provider alone, without /retrieval/)
2. Create implementation PR in GO (https://github.com/ipfs/boxo/tree/main/gateway used by Rainbow and Kubo/Desktop) and JS (Helia/verified-fetch) to ensure the spec is clear enough to be implemented in two different places
3. Merge the spec once no concerns were raised and after both implementations shipped and work the same.

[vasco-santos]

For visibility, we discussed out of bound and agreed on a first stage:

1. Make provider query parameter in helia be behind a flag
2. Draft PR with IPIP to specs with query parameter (no protocol encoding for now)
3. Enable inbrowser.link to be able to use this on its configuration

Hopefully, we can then iterate a next step after user validation and feedback for:

1. Add this to Kubo/Go side
2. Make it the default + Finish/Merge the IPIP
3. (Eventually) extend this with protocol encoding in multiaddr

[vasco-santos]

Here is the IPIP draft to the specs repo ipfs/specs#504