Kubemark is very useful tool for exercising various solutions requiring to run
many nodes on a small set of physical nodes. E.g. for development and testing
of cluster autoscaler where some use cases might require tens or hundreds
of nodes to be scalled up and down. Using kubemark saves computation
resources.

As part of integration of cluster-api project into cluster-autoscaler project,
the autoscaler uses the ProviderID field to index nodes through informer.
Setting the ProviderID field even by Kubemark allows to autoscale cluster
made of hollow nodes.

The main purpose of Kubemark is to allow register more virtual nodes
than there is physical ones. Yet, presenting all the virtuals nodes
as real ones by running kubelet with fake container runtime.

Though, the real nodes can manifest in many ways (e.g. nodes going
into Unready status, nodes reporting disk pressure) that Kubemark
can not currently simulate. Providing a way to configure hollow node
to e.g. go Unready would help to improve ability to cover more
testing scenarios.

In case of cluster-api nodes are backed up by machine objects.
One of the goals of the cluster-api project is to improve self-healing
ability of a cluster, Allowing a node to conditionally go unready allows
to test a case of self-healing machine which is not easy to reproduce
in a cluster with only real nodes.

This PR gives kubelet the ability to inject external runtime health checker.
In case of Kubemark ability to inject runtime disruptor that allows
Kubelet runtime to conditionally report error causing a node to report
unreadiness.

The main purpose of Kubemark is to allow register more virtual nodes
than there is physical ones. Yet, presenting all the virtuals nodes
as real ones by running kubelet with fake container runtime.

Though, the real nodes can manifest in many ways (e.g. nodes going
into Unready status, nodes reporting disk pressure) that Kubemark
can not currently simulate. Providing a way to configure hollow node
to e.g. go Unready would help to improve ability to cover more
testing scenarios.

In case of cluster-api nodes are backed up by machine objects.
One of the goals of the cluster-api project is to improve self-healing
ability of a cluster, Allowing a node to conditionally go unready allows
to test a case of self-healing machine which is not easy to reproduce
in a cluster with only real nodes.

This PR gives kubemark the ability to:
- configure kubelet to force node status to report unreadiness (either indefinitely or periodically)
- set node taint to NoSchedule
- change node status update frequency

Examples:
- Start reporting Node status Unready after 40s from the kubelet startup:
  $ ./kubemark ... --turn-unhealthy-after=true --healthy-duration=40s
- Switch node status to Unready after 40s in Ready status to Unready for 5s and back to Ready periodically
  $ ./kubemark ... --turn-unhealthy-periodically=true --unhealthy-duration=5s --healthy-duration=40s