Decouple Lokomotive versioning from lokoctl

[iaguis]

Currently the Lokomotive version is embedded in the lokoctl binary. That is, to update Lokomotive you need to get the new lokoctl binary and run lokoctl cluster apply.

We should consider decoupling the Lokomotive version from lokoctl and have some kind of release manifest.

[invidian]

I have some ideas how to address that.

[invidian]

TL;DR I'd like to try implementing decoupling using Go plugins and this comment will be dump for my findings:

• Some finding about loading plugins:

  FATA[0000] Getting release: opening plugin ./release.so: plugin.Open("./release"): plugin was built with a different version of package github.com/kinvolk/lokomotive/pkg/release  command="lokoctl 
  component list"
  

  It seems imports should be well isolated, so perhaps it would make sense to put lokoctl into separate Go module (with own go.mod file), to enforce proper imports.

• Go plugins cannot be statically linked, so they are not portable across distros 😞 See plugin: requires CGO_ENABLED=1 golang/go#19569 for more details.

• Having Don't use globals for handling components and platforms registration #597 solved would simplify the isolation.

[invidian]

So, the main thing I struggle right now with Go plugins implementation is fact, that github.com/kinvolk/lokomotive/pkg/assets package import must be only imported in the release plugin code and not in cli/cmd package. This is required, as otherwise embedded assets files are still taken from the lokoctl binary rather than from release.so file.

This turns out to be surprisingly difficult because of the way our code is structured.

The fact that CLI code currently implements most of the cluster operations logic rather than just being a gate to trigger it is a problem. We also have many tiny imports, which additionally clutters the dependencies tree and we still use #630 in too many places, which makes it more difficult to move code around.