Add peer filters per Request

[hannahhoward]

Goals

This adds a query parameter which can be used multiple times, called "peer-filter". The syntax for the value is: peer id as string + optional ~ followed by comma seperated protocol list

So: QmPeerIDFoo~bitswap or QmPeerIDFoo~bitswap,graphsync or just QmPeerIDFoo. If no ~ is present the peer is filtered entirely. If ~ is present, the specified list of protocols are filtered out.

This is my proposed solution for #207 but want to get buy in before I put in all the tests.

between this, the "protocols" param, and the "providers" param, this should enable us to do various A-B test experiments with Saturn, and also provides a solution for eIPFS bitswap filtered.

I'd rather leave percentages to Saturn code specifically to do dice rolling on its own.

[codecov-commenter]

Codecov Report

Merging #228 (ea661f5) into main (912e5ab) will decrease coverage by 0.71%.
The diff coverage is 11.36%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #228      +/-   ##
==========================================
- Coverage   70.74%   70.04%   -0.71%     
==========================================
  Files          62       62              
  Lines        5274     5314      +40     
==========================================
- Hits         3731     3722       -9     
- Misses       1347     1389      +42     
- Partials      196      203       +7     

Impacted Files	Coverage Δ
pkg/types/request.go	60.49% <ø> (-0.49%)	⬇️
pkg/server/http/ipfs.go	54.32% <8.00%> (-5.32%)	⬇️
pkg/retriever/protocolsplitter.go	52.94% <15.78%> (-47.06%)	⬇️

... and 5 files with indirect coverage changes

[rvagg]

OK, but this is pretty narrow and not really likely to be used with anything other than the eipfs peer ID. It also relies on upstream to do all of the a/b dice-rolling before calling lassie, which is fine if that works better in the L1 than it does being hardwired as a parameter in Docker or in the query string. I imagined this being encoded in an environment variable in the Dockerfile for the L1 with %'s baked in. But if it's easier to just do that % work in the L1 Express app then that works too.

[willscott]

I have no problem with a more powerful exclusion language here, though I don't think we need this power in any immediate term - all of the provider IDs we expect to want to block, we'll want to block fully.

I think the other challenge here is that in many cases peer IDs aren't long-term stable (e.g. the kubo gateways, infura) - so actual long-term identification of a peer we want to exclude ends up being more challening that a static list in an env var.