Additional routes for cuhttp

[willscott]

Checklist

• This is not a question or a support request. If you have any Curio related questions, please ask in the discussion forum.
• This is not a new feature request. If it is, please file a feature request instead.
• I have searched on the issue tracker and the discussion forum, and there is no existing related issue or discussion.
• I am running the Latest release, or the most recent RC(release candidate) for the upcoming release or the dev branch(master), or have an issue updating to any of these.

Curio component

• PoRep Pipeline
• Snap Deals
• Market
• IPNI provider
• Curio UI
• Other

Improvement Suggestion

Currently the http endpoint has routes to get pieces and individual data CIDs, along with IPNI advertisements.

There have been other semantics to this server that would be great to add.

This issue is meant as a tracking issue, and also to identify if there is any objection from the curio team if these additions are provided in a PR.

Metadata route

As an extension to the current /piece/<piececid> route, it is proposed to add a /piece/<piececid>/metadata.json route. This route will return metadata about the piece as a json record. In particular, the information to provide mirrors what would be in the associated deal structure if it were to be a market deal, and in particular:

{
   "Size": 0,
   "StartEpoch": 0,
   "EndEpoch": 0,
   "Client":  "f0...",
}

In addition to these keys that will be present, additional keys may be provided, including

{
   "Claim": "045...",
}

Motivation:
the presence of this metadata endpoint will provide an API for a proxy in front of the curio http server to make decisions about piece requests to meet policy, e.g. only storing data that's stored by specific clients, or that are needed to meet fil+ policies.

Sealed route

The current route /piece/<piececid> reads data from an unsealed piece when given a 'commD' piece CID. If no unsealed piece exists it may depending on policy attempt to unseal, or will fail.

The proposal is to provide support for /piece/<piececid> to handle requests where the provided piece CID is a commR referencing the specific sealed replica data.

Motivation:
This will allow for in-band transfer of sealed data, in cases where unsealing should be offloaded to a different machine with compute available.