Homogenize zapp execution command line semantics

[larsbutler]

For either local or remote execution, the command runner should generate a job.json (like a ZeroCloud servlet). This can already be consumed by ZeroCloud, and the local execution mechanism should be extended to consume the same thing.

The advantage to this is the we formalize an execution, which makes it easier to switch between remote and local execution environments, reason about both, and to develop/extend clients for these execution platforms.

Further work:

Discussing this with Martin, we think it would be a good idea to create a sort of "preprocessor" interface, which consumes a zapp (file) and the command line arguments and produces the job.json.

TODO: Look at zvapp in zerovm-cli; apparently it can execute parallelized jobs locally? I've never played with this. If this is true, it should be extended to consume a job.json blob, just like ZeroCloud.

[pkit]

Zvapp should be able to do it. Even parallelized ones.
The problem with current zvapp is that it depends on zerocloud
Probably not a big deal but feels wrong...
P.S. I mean it imports stuff from zerocloud, not runs zerocloud inside :)

[larsbutler]

@pkit Oh yeah, I had forgotten about that dependency. Yeah, we should try to fix that somehow.

[mgeisler]

@pkit

The problem with current zvapp is that it depends on zerocloud
Probably not a big deal but feels wrong...

Why is this wrong? I would expect a local execution to reuse some code from ZeroCloud. Maybe you are really concerned that ZeroCloud depends on Swift and thus zvapp also depends on Swift? If that's a problem, one might be able to extract the reusable part of ZeroCloud into a base package (without further dependencies) and let ZeroCloud and zvapp both depend on this.

[pkit]

Yes, the main problem is that it fetches a lot of Swift and Swift-related stuff.
I think we can try to transfer config-parser related stuff to zerovm-cli, and then make zerocloud depend on cli tools.