Report which deployment is live on each node, and which releases each node keeps #3059

Part of #641.

Problem

Since 5.3.0 each node keeps staged builds, and the releases a deploy replaced, under .deploy-staging/<deployment_id>. Going back to one is deploy_component { deployment_id } (#2315, steps 5 and 6). But nothing tells a client which release is live, or which ids it can go back to:

• get_components deliberately skips .deploy-staging and each component's provenance marker, .harper-deployment.json (getComponents in components/operations.js).
• list_deployments lists the records the origin wrote. It can't say which of those a node still keeps:
  • retention (deployment.stagingRetention.maxCount) prunes per node;
  • a release made live before 5.3.0, or deployed from a file: directory, isn't kept;
  • a node that joined later never had the older releases.
• Activating an id a node doesn't keep answers 404, so today the only way to find out is to try.

Studio's rollback (HarperFast/studio#1232) and deployments page (HarperFast/studio#1786) need this so they offer only targets that will work. The CLI could use it for harper deploy deployment_id=….

Proposal

Report, per component and per node:

• The live release. The deployment_id of the live release, read from its provenance marker. It's absent for a tree with no marker, such as one installed before 5.3.0 or by add_component.

• The kept releases. The releases kept under .deploy-staging, each with:

  • its deployment_id;
  • whether it's staged (never activated) or kept (replaced);
  • when it was built or replaced;
  • its size on disk.

  Skip residue, and builds owned by a different component, as retention already does.

Put this on each get_components entry, next to status. It also needs an answer for the whole cluster, because a node's answer only describes that node. Either get_components gains a replicated form that returns each node's view, or a small list_releases { project, replicated } operation does.

#3048 adds preview metadata from the same provenance file to get_components, so share the reading.

Related

• Track per-application deployment and restart timestamps #564 asks for per-application deploy and restart timestamps. Once this exists, the live release's record answers "deployed when".

Done when

Deploy a component three times on a two-node cluster, then stage a fourth release. Each node reports the live deployment_id, two kept releases and one staged release. A release pruned on one node is missing from that node's answer only.