Optimize pillar/zedbox memory usage

[eriknordmark]

The history is that at first we had separate golang binaries (for each of pkg/pillar/cmd/) but the disk image size of each one of them was >10Mbytes and it seemed wasteful to have 10-12 of them. So we introduced a single zedbox binary with symlinks (from /opt/zededa/bin/ to zedbox) thus the total disk space usage was about 30Mbytes.

A few years later we realize that the total memory usage (RSS) for these processes could grow quite large. To address this we made zedbox run as a service (where each /opt/zededa/bin/* would request zedbox to start a service - unless run as inline). The service is implemented by the single zedbox process calling the Run() function for the service, which kicks off its go routines.
This made total RSS consumption smaller. But is is still quite large.

Note that none of the above changes had any impact on the structure of each pillar microservice - apart from the main() function being renamed to Run(). Thus it should be easy to revert this to having separate processes.

It turns out that the disk size of the binaries is not a concern, so if we can get a handle on the RSS consumption it would make sense to have smaller go binaries. That would also have some security benefits since it would later allow us to use standard linux mechanisms to restrict which pillar microservices can access the network or various directories etc.

So the question is can be make either the current zedbox process have smaller RSS, or break apart into separate processes for each /opt/zededa/bin/* and have those have smaller RSS. It is not clear whether this RSS comes from init code in the various golang packages, but having smaller processes with less package imports would presumably make this easier to investigate.