activation: support multiple smeshers

[fasmat]

Description

To fully utilise the separation of PoST from go-spacemesh a node needs to be able to handle multiple post services simultaneously.

Acceptance criteria

• Allow multiple PoST services to connect via the grpc interface.
• Code in the activation package needs to be updated to handle multiple identities correctly.
  • The activation package builds an ATX for every identity that is set up for the node and has a post service connected
  • Only one post service per identity can connect to a node
• Connections from PoST services over public interfaces have to be authenticated with mTLS
  • Assume that both sides have each others certificate

Implementation hints

• The general design of the setup is described here: Post as a service pm#259
• Consider storing the nipost builder state, - challenge, and initial post in the DB instead of on disk (post.bin, nipost_challenge.bin and nipost_builder_state.bin).
  • There will be at least one initial post and at least one nipost challenge for every identity managed by the node
  • Also consider splitting the builder state into one state for each identiy & poet combination, so they can be tracked individually.
  • Add second database for local state #5206

[dshulyak]

ideally we also should skip post validation for self-published atxs

[fasmat]

ideally we also should skip post validation for self-published atxs

validation in the NiPost builder was already removed in #5061. The activation package trusts the post service to deliver a valid proof and creates an ATX with it. That ATX however will still be validated (including proof validation) before/as part of broadcasting it, I think.

[fasmat]

Removing the dedicated validation of the NIPostBuilder lead to some (rare) cases where publishing of an ATX might result in weird behaviour:

• if the activation.Builder successfully publishes an ATX but fails to persist that it did, it might publish a second ATX causing the node to create a malfeasance proof against itself
  • this should be changed to instead fail the ATX verification but without creating the malfeasance proof against oneself
• there were cases reported where the broadcast of the ATX failed (due to a falling validation by the activation handler). The activation.Builder however seems to still consider it a successful Publication and continues with the next ATX.
  • this won't lead to any adverse effects for the node (besides missing rewards - but the ATX would have been invalid anyway).
  • This is more a nuisance as the logs won't report what happened correctly: the NIPostBuilder and activation.Builder both report that they were successful and only the activation.Handler reports that it failed to validate an ATX (which appears to be an incoming ATX, but with she SmesherID being the same as the Nodes ID)
  • here the logging should be improved to more easily identify when this happens.