Offer diagnostics APIs to expose further detail about deal proposal lifecycle

[masih]

Expose more information about deals that are either in the making or have been made in order to enable ISVs to investigate potential system issues. This is particularly useful for resolving issues related to out-of-bounds interaction between ISV and the SP.

[andrewferrone]

As a client, after posting a blob to Motion, I would want to know more about what's happening with my blob for the purposes of troubleshooting. Some ideas for statuses:
a) queued for preparation (in a local queue awaiting CAR file generation)
b) preparing (packing CAR file and calculating CommP)
c) queued for deal-making
c) making deals (at least one deal has been proposed - ideally response would include an array of the SPs to which deals have been sent and the status of the last deal proposed to each SP with a timestamp of when it was proposed, statuses may include pending acceptance, accepted with timestamp, transmitting with progress [timestamp started, bytes transmitted, bytes remaining], queued for sealing with timestamp, sealing with timestamp, sealed, failed [with reason])
d) complete (full number of replicas have been sealed and verified)

[xinaxu]

It seems that for each boost proposal, we will need to query the boost SP and update the status in database.

Should this be done in Singularity (my preference), or should Singularity expose the Boost proposal IDs to motion.

[masih]

I agree that it should be done in singularity