Support for dev image

[kwypchlo]

Due to debugging constraints when working with a pre-compiled binaries we should provide a dev image that:

• has /bin/bash shell (compared to limited /bin/ash from alpine)
• when logged in to shell: has all the tools like curl, wget, zip, vim, nano etc installed (@DavidVorick can you collaborate on that list)
• when logged in to shell: has a local copy of Sia repo so anyone can change a line and run make to recompile the binaries and restart a container (needs full go environment)
• when logged in to shell: has go env path in the PATH so you can run siac and siad after you recompile the binaries with make

The idea is to be able to debug production servers like this:

1. turn off health-check and wait for the server to be out of load balancer
2. run docker stop sia to stop the sia container
3. change the image in docker-compose.yml to dev
4. run docker exec -it sia /bin/bash to ssh to sia container
5. you should be in ~/Sia git directory where the master is checked out
6. you change branch or edit your changes and run make to compile binaries
7. run exit to exit sia container shell
8. run docker restart sia to restart sia container with your changes on it

[ro-tex]

So, we need a second container, alongside the main production container that the portal is going to be using. This second container should have the dev tools needed to build siad and the source code. This part is easy and straightforward.

The debug container should be able to build siac and siad binaries which, crucially, should be used by the main production container after it's restarted. No problem there but there are some considerations.

The way to do it:

• create a new dir on the server and mount it as a volume on both the production and debug containers
• add this volume to the PATH of the production container before /usr/bin, so when the container is restarted and tries to execute siad from the PATH it will run the version from the volume
• from the debug container we can build siac and siad and copy them to the volume and then restart the production container

Considerations:

• the production container will be blindly running a binary that's provided to it via a volume and this is a security consideration. I'm not sure how severe that is because anyone who can place a binary there should also be able to control docker.
• the process is quite clunky and doesn't allow the developer to locally test the binary before sending it to the production container, unless we keep a second copy of the consensus to be used from the debug container.
• if we use a second copy of the consensus, maybe we can copy the consensus mounted on the production image, strip all wallet-related data and reinitialize it for the new node. I could need some guidance here in order to not miss anything.

[ro-tex]

@kwypchlo your proposal can definitely work. I actually like it more than mine. Let's do that.