Introduce start_miner|config|packet_forwarder keys to control start order

[vpetersson]

With the new rewrite where we fully decommissioned the hm-gwmfr, the fist service that we need to start up is the diagnostics tool. Moreover, it is somewhat challenging to control the startup order of the other services, as there is a lot of inter-dependency between these services.

As the /json end-point is now becoming more stable, we should be able to use this as a control mechanism for the startup order.

This could look something like this:

{
[...]
  "start_miner": false,
  "start_config": false,
  "start_packet_forwarder": true
[...]
}

We can then have a simple check in the startup script for each container that would look something like this:

function ready_to_start() {
    curl -s https://diag/json | jq --exit-status .start_config
    echo $?
}

while not ready_to_start; do
    echo "Not ready to start"
    sleep 5
done

In short, we evaluate the start_config key from the payload. If this returns false, jq will exit with exit code 1, and thus the loop will not evaluate true.

Later on, we can make this more elegant and move the logic straight into the Dockerfile using the HEALTHCHECK option and then move this check to docker-compose.yml using the following stanza:

depends_on:
  db:
    condition: service_healthy

This is unfortunately still not supported in Balena, so we need to stick with the above startup script logic for now.

(NebraLtd/helium-miner-software#177 also touches on this logic)

Checklist

• Build out the requirements for start_miner
• Build out the requirements for start_config
• Build out the requirements for start_packet_forwarder

[marvinmarnold]

Relevant Slack convo about start miner-pktfwd start order: https://nebraltd.slack.com/archives/C024BNQ1Y6T/p1635446056108700?thread_ts=1635443237.106000&cid=C024BNQ1Y6T