Switch unknown providers at /routing/v1/providers to peer schema

[lidel]

Currently, cid.contact returns all HTTP nft.storage announcements like this (example):

{
  "Protocol":"unknown",
  "Schema":"unknown",
  "ID":"QmUA9D3H7HeCYsirB3KmPSvZh3dNXMZas6Lwgr4fv1HTTp",
  "Addrs":["/dns4/dag.w3s.link/tcp/443/https"]
}

The problem is that results with "Schema":"unknown" are being ignored by boxo client (conformed in ipfs/boxo#422 (comment)), and we would like Kubo and other users of boxo client library to access ID and Addrs information present there (+ setting standard for doing the same in JS in Helia).

@masih would it be possible to change to Schema: "peer" (from IPIP-417) for these /routing/v1/providers responses?

All we need is:

{
- "Protocol":"unknown",
- "Schema":"unknown",
+ "Schema":"peer",
  "ID":"QmUA9D3H7HeCYsirB3KmPSvZh3dNXMZas6Lwgr4fv1HTTp",
  "Addrs":["/dns4/dag.w3s.link/tcp/443/https"]
}

[masih]

Of course 👍 OK to action this next week?

[lidel]

@masih yes, any time in next 2 weeks will be 👍

[masih]

@lidel Question: is there anything to coordinate on in terms of breaking changes? Cc @gammazero

[lidel]

@masih no, afaik the change is that Kubo 0.22 is ignoring unknown results, and Kubo 0.23 will start supporting peer results.

Switching from unknown to peer will enable Kubo to see them and act on them.
This is prerequisite for future Kubo to be able to do HTTP retrieval when /https multiaddr is present (which will reduce costs for groups like dotStorage).