Kubeproxy logs are filled with redudnant version check spam from an unexported call that's invoked
as part of checking if a feature is supported. The logs don't detail what feature(s) are even being checked
so it just seems like spam. With the way things are implemented all of the hcn features are checked for support in
any of the `hcn.XSupported()` calls not just the one being checked, so these logs come up quite a bit if there's
many features that aren't supported on the machine.

Add two new logs in a sync.Once that logs the HNS version and supported features. This should be enough
to investigate version issues.

Should remedy #1043

Signed-off-by: Daniel Canter <[email protected]>
(cherry picked from commit 6288bb9)
Signed-off-by: Daniel Canter <[email protected]>

To avoid a breaking change on GetSupportedFeatures introduce a new
GetCachedSupportedFeatures method. This method does the feature check
and version parsing once and then assigns a global with the information.
This can be used to optimize for situations where many uses of the
hcn.IsXSupported methods are going to be used (kube-proxy for example).

Signed-off-by: Daniel Canter <[email protected]>
(cherry picked from commit 112b5e7)
Signed-off-by: Daniel Canter <[email protected]>

- Change versionErr -> featuresErr
- Move work inside of the sync.Once out to its own function so we
can use standard return err error handling and simply assign the
output in GetCachedSupportedFeatures
- Mark GetSupportedFeatures as deprecated.

Signed-off-by: Daniel Canter <[email protected]>
(cherry picked from commit f78d0ff)
Signed-off-by: Daniel Canter <[email protected]>

Signed-off-by: Daniel Canter <[email protected]>
(cherry picked from commit 16435c7)
Signed-off-by: Daniel Canter <[email protected]>

Signed-off-by: Daniel Canter <[email protected]>
(cherry picked from commit 57c5d60)
Signed-off-by: Daniel Canter <[email protected]>

This change adds a simple retry loop to handle some behavior on RS5. Loopback VHDs
used to be mounted in a different manor on RS5 (ws2019) which led to some
very odd cases where things would succeed when they shouldn't have, or we'd simply
timeout if an operation took too long. Many parallel invocations of this code path
and stressing the machine seem to bring out the issues, but all of the possible failure
paths that bring about the errors we have observed aren't known.

On 19h1+ this retry loop shouldn't be needed, but the logic is to leave the loop if everything succeeded so this is harmless
and shouldn't need a version check.

Signed-off-by: Daniel Canter <[email protected]>
(cherry picked from commit 01b9911)
Signed-off-by: Daniel Canter <[email protected]>

This change adds a small sleep before a re-attempt on layer operation
failures. These failures should only happen on RS5 and the probable cause is because
of a different way in which container loopback vhds were mounted on this OS version.
A theory of why things might go awry on RS5 is due to some events from pnp getting reported
too late/early. If the prognosis is correct, a small sleep might help to try and get
things back into a "good" state before a reattempt.

Signed-off-by: Daniel Canter <[email protected]>
(cherry picked from commit adc35b0)
Signed-off-by: Daniel Canter <[email protected]>

Signed-off-by: James Sturtevant <[email protected]>
(cherry picked from commit 11375bf)
Signed-off-by: Daniel Canter <[email protected]>

Signed-off-by: James Sturtevant <[email protected]>
(cherry picked from commit f8784aa)
Signed-off-by: Daniel Canter <[email protected]>

[release/0.8] Cherry-pick PrepareLayer fixes

[release/0.8] Cherry-pick HNS Network stats functionality

[release/0.8] Cherry-pick hcn feature check improvements

Due to some unfortunate deps in the root go.mod in containerd + some k8s staging
directory behavior, containerd 1.5 errors out when trying to get vendored into
kubernetes/kubernetes. Because we depend on ctrd 1.5, if hcsshim tries to
get bumped it will ask that we also bump their dep of containerd to 1.5
and things will fail also. This reverts our containerd dep for the release/0.8
branch to 1.4 so we're able to circumvent this, at least temporarily.

Issue tracking this problem that contains k8s proposed solution and statements on
this: kubernetes/kubernetes#104827

"Components that have a transitive dependency to anything in k8s.io/kubernetes,
including the staging components, can not be added as a dependency. The
detection and prevention of this in the dependency management scripts is
intentional."

While this work is temporary just to get k8s a new hcsshim release, longer
term we will need to find a way to trim our containerd dep either here, or
containerd will need to get rid of it's k8s.io/* dependencies in their root go.mod
to remove this circular import issue.

The tests ran to make sure nothing broke with this
---------------------------------------------------------------------
-All of the tests that currently get ran on a K8s pull request which includes
the AKS engine e2e containerd test suite.
-Containerd integration tests
-Our cri-containerd tests with a shim built from this commit

Signed-off-by: Daniel Canter <[email protected]>

[release/0.8] Revert containerd dep to 1.4.9