API & dashboard showing RSR for HTTP retrievals (HTTP-RSR)

[bajtos]

At the moment, Spark RSR is defined as how many retrievals succeeded using HTTP or Graphsync protocol for CAR transfer.

Let's add another RSR (HTTP-RSR) defined as follows: how many retrievals succeeded using HTTP protocol for CAR transfer. (A retrieval that had to use Graphsync because the SP does not advertise HTTP is considered as a failure.)

We should provide all usual flavours for this RSR:

• Network-wide RSR from all measurements
• Network-wide RSR using only measurements targeting miners with non-zero HTTP-RSR rate
• Per-miner RSR

What are the benefits:

• Spark v2 will support only HTTP, not Graphsync. This new score will show us the gap, show us how bad the breaking change between Spark v1 and v2 is going to be. (Note that this does not paint the full picture as there will be more breaking changes between Spark v1 and v2.)
• Spark RSR consumers like the FIL+ Allocator Compliance process can start issuing a warning to SPs that don't offer HTTP retrievals. They can even decide to switch from the current RSR to HTTP-RSR in the future.

Why I want to keep the current RSR around:

• Don't break our chart showing how Spark drove improvements in the RSR over time.
• Avoid breaking changes to consumers. Let them decide what's the right time to switch and how to make the switch least disrupting to their users.

/cc @willscott, you were interested in having this data