Bootstrapping the etcd.target service on master.project and cleaning up the systemd startup process

[arizvisa]

The way the etcd.target service is bootstrapped is done at the incorrect time when building master.project. It's actually happening as part of the "master-bootstrap" environment when provisioning the template with salt-masterless at build-time, when really it should be happening at deploy-time. If issue #8 gets solved, then it would be significantly better to somehow do this as part of the process of provisioning with the "master" environment.

If at all possible, the "master" environment could detect other members of the cluster and use that to identify whether it's responsible for bootstrapping the instance of etcd. If this ends up being a valid solution, then we can also use the same logic to automatically deploy a distributed MinIO cluster with the store state, as well as one for Kafka too with the queue state. If absolutely all of this works properly, then we could even deploy k8s by default and simplify our container management too. However, this might still be clumsy, because we definitely _need_ the etcd instance to be running in order to manage job results returned by the "master" environment.

At the moment the usage of Terraform allows us to hack around this, but Terraform is not yet completely integrated into this project because of the immaturity of the terraform-provider-vsphere plugin.