feat: add support for experimental provider query parameter

[vasco-santos]

Add support for experimental provider query parameter

Description

Bubbles up feature added in ipfs/helia-verified-fetch#242

Notes & open questions

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

[SgtPooki]

I don't think we need many of these changes here TBH, but I'm open to discussing..

Is there a reason we would want to allow people to disable an optional parameter they may not even be aware of?

[SgtPooki]

I don't know if we need to toggle this on or off, as most queries won't contain it, and we can just check for it. That means we don't need all the config updates either

[SgtPooki]

Consider removing if we don't need the config-page updates.

event.request.url should contain the whole request string, including query parameters.

[vasco-santos]

@SgtPooki thanks for looking into this.

This PR needs the PR mentioned in PR description though ipfs/helia-verified-fetch#242 and it is still not finalized.

Based on @lidel 's request, ipfs/helia-verified-fetch#242 adds the provider parameter behind a feature flag, and disabled by default. With that in mind, the only way to follow same behaviour and be consitent is by manually toggling it. In my opinion, it would not make sense that in @helia/verified-fetch we would need to pass a flag to use this, even if for the most part there will be no ?provider=..., but here the opposite happens.

@SgtPooki do you have any reasons in mind why this should be by default on here?

[SgtPooki]

@SgtPooki do you have any reasons in mind why this should be by default on here?

@vasco-santos IMO: the query parameter is a "config toggle" itself.. so why do we need a config toggle in the UI?

If it's optionally enable-able in verified-fetch, then we can enable that verified-fetch setting in this repo, and those who pass the parameter to inbrowser.tld are choosing to use it.

The only benefits I see with adding this as a UI config toggle on inbrowser.tld:

1. communicating the availability of that functionality to users.
2. preventing provider hints from being used even when they are in the URL (maybe user is cautious about sending WANTs to supposed "providers") -- Do we have things in the spec to discuss security and client-tracking potential of these provider hints? I didn't see anything and added a comment https://github.com/ipfs/specs/pull/504/files#r2138147462.

---

Honestly, the main reason I am against adding a UI toggle for this experimental feature is that the config is already somewhat unwieldy.

[vasco-santos]

@lidel mind raising here reasons behind the option to make provider work related to not put other implementations at disadvantage?

To be clear @SgtPooki , I would of course prefer to not have flags to make this more difficult to use, but most of the shipyard team told me this was essential.