Check how PoST Proof generation handles missing / corrupted data

[fasmat]

Description

When generating a PoST proof a node can fail to read data from disk, when some or all of the PoST data was deleted, or it could generate a proof based on corrupted / altered PoST data.

Acceptance criteria

• A node must verify a generated proof after creating it.
  • If the proof is detected as invalid mark the used label indices as corrupted and try again (only once)
  • Failing to generate a proof must be logged such that an operator of a node is informed
• If data is lost by disk failure or data corruption, the operator should be informed and given the option to continue smeshing with a smaller NumUnit value.
  • Define the limit of lost/corrupted data that triggers the notification to the operator.
  • Define an API for via which smapp is signalled to display the information and give the operator the choice to stop smeshing or decrease the NumUnits value.
  • If the operator chooses to decrease the NumUnits value update the post metadata such that the next time an ATX is published is uses the lower value.
  • If the user fails to respond before the deadline to create and publish an ATX automatically disable smashing.

After genesis

• The operator is given the option to recreate the missing data and increase their PoST size again.

[poszu]

Reassigning to @fasmat as he is currently redesigning the POST path.