spike: Docker-compose for local setup

[Anmol1696]

Overview

As a user, one does not care where and how the system is being run as long as it is consistent, locally, on the CI and in the cluster.

Running k8s locally is still a bit of a hassle with docker-desktop it becomes a little easy.

Proposal

What if we allow users to define a simple config file, but then still be able to run that with docker-compose. We will solve the local issues.
We can restrict the number of nodes to be spun as well as not allow multi-validator setup, but basically give users a development environment of there choices.

Design

We would have to redo alot of stuff that k8s provides for free, mostly around init-containers, templating with helm and more to get this to work. But this would be a good feature to have for local testing.

User inputs

Users still just needs to provide a simple config file as input, same configuration, and we can create a docker-compose template for running it, first via the Makefile, then via the cli.

Multiple backend supports would be really big for Starship, specially for the initial hurdle of onboarding users to Starship.

NOTE: We would need to restrict the features for docker-compose based on the limitations of the framework itself.

[Anmol1696]

With more and more features being added to Starship helm charts, we need a way to have a complimentary solution for local environment.

docker-compose seem to be able to have init-containers as well, with something like:
https://github.com/zeitounator/compose-init-demo/blob/main/docker-compose.yml

Our main usecase of k8s at this point is around:

• init-containers
• side-cars
• lifecycle hook: specially to create-validator
• configmaps

We should be able to replicate alot of the systems we have, and scripts we have for helm to be used for docker-compose creation.

[Anmol1696]

We would need something like: https://github.com/tiagomelo/golang-yaml-template-tutorial/blob/main/parser/parser.go
To be able to create docker-compose yaml file from config file. For this we would have to create our own custom parser as well and inject information as needed too. But this is a good start.

[Anmol1696]

Docker-compose yaml file output, can be less of a templating solution, and more of objects and structs that represent the final docker file, and based on some inputs, we create the final object, with dependency injection. That way we can move all the logic to custom go code, and deal with structs and go custom types instead of templates.

Again just the output of this system needs to yaml, not the internal model of the system, which is not anyways.