Remove POS data initialization from go-spacemesh node

[poszu]

Status quo

The POS data initialization is built into the go-spacemesh node. It complicates the code but is not very useful. Users could be divided into two main groups:

1. CLI users (users who run the go-spacemesh node directly). They usually initialize using the postcli tool as it gives more flexibility and is more straightforward.
2. We ignore existence of Smapp as Smapp will be mainly refactored with the node-split

Proposal

The proposal is to remove initialization implementation from go-spacemesh.

Steps

• Remove initialization from go-spacemesh
• split post-rs library into initialization (depends on OpenCL in the system) and verification (doesn't depend on OpenCL) - as go-spacemesh would only use the latter, it wouldn't require an OpenCL runtime in the system to run

Notes

It would be best to first refactor smapp to use postcli and run it in production for a while. In case something goes wrong, it would be easier to rollback. After the new initialization way is proven to work nicely, we can proceed and remove init from go-spacemesh.

[Stizerg]

@poszu Regarding #2. While I agree that it's more flexible to use postcli for POS initialization, I can't agree with that statement. I know that a lot of people using go-sm to init POS. Yes, it makes sense to remove that code from go-sm. Can go-sm call postcli as external function?

[fasmat]

Looks good so far, what I'm missing:

• We should ship postcli as part of the official go-spacemesh docker image (and release archive) and update the documentation on how to use it (natively and with docker)
• We need to update our system tests to use an init-container (either go-spacemesh with postcli or the existing postcli docker image) for post initialization for nodes with supervised smeshing (remote smeshing nodes already use postcli docker image for init).

[fasmat]

@Stizerg: the primary reason we remove init from the node is because

a) the node right now requires OpenCL to be installed on your system only because of it - if we remove init from the node it can be installed and operated on a system without OpenCL
b) initialization with the node is less flexible and more easy to make mistakes with (i.e. deleting files) than when using postcli. This also isn't easy to be fixed without breaking other things in the node.
c) with init removed from the node, initialization and sync can be controlled individually more easily.

It should also be easier to build a nice UI around postcli for initialization than around go-spacemesh.