Openwhisk: Implement a new ContainerPool based on reactive patterns

[markusthoemmes]

Implement an entirely new ContainerPool (and eventually Invoker) which is based entirely on an event- and message-driven architecture. It does not use any busy-loops nor manually tweaked Thread.sleeps to distribute its work. As a consequence, this pool does not need locking or synchronized access to any data-structures.

Containers are modeled as a finite-state-machine to reflect the lifecycle of a container in the code itself as close as possible.

The new pool can factor in all the bits and pieces we learned over the development of the current pool. It needs to have testability in mind as a first-class-citizen to facilitate Invoker simulation and therefore simplify playing around with different scheduling algorithms.

[markusthoemmes]

All pull-requests relative to this epic are open and ready for review. For convenience, here's how they add up:

• #2161 (DockerClientWithFileAccess)
• #2107 (ContainerProxy)

Those two can be reviewed and merged independently. They should be merged before:

• #2151 (ContainerPool)
• #2177 (DockerContainer)

Those two again should be independently review-/and mergeable. After the first two have been merged, the latter should be rebased to incooperate any changes that might apply.

After those 4 requests are in, I'll assemble a final PR which will hook up the ContainerPool + DockerContainer with the invoker as seen in #2021. Note that #2021 is only the "big picture" PR. It does not need to be reviewed nor merged. It only lives there to keep continuous track of our testcoverage and that we didn't introduce regressions.

@rabbah @jeremiaswerner FYI

[rabbah]

@markusthoemmes done?

[markusthoemmes]

Indeed.