feat(secrets): add support for decrypting kube configs

[KathrynLewis]

Part of secrets management project: spinnaker/spinnaker#3649

So far, we've been adding an autowired SecretSessionManager to deal with decryption, but kube configs are handled in static methods in KubernetesV2Utils. Since you can't static autowire, it seems the cleanest solution is to make those methods non-static and make adjustments in the couple classes that call them.

We also have to remove the static autowire in Kubernetesv1Utils, so secrets in v1 kubernetes is unsupported for now.

[KathrynLewis]

@lwander @ttomsu Do either of you have a chance to take a look at this one?

[ttomsu]

I think the name is what's throwing me here. That, and not following all of the specifics in the changes thus far.

[ttomsu]

I'm personally not a fan of making a class with Utils in the name a field. I worked on a previous project that had objects, each with their own Utils object and it didn't mesh well in my head.

[KathrynLewis]

This seemed like the cleanest workaround to avoid the static autowire issue explained above. Another kind of clunky alternative is to leave secretSessionManager as static and add a class that creates an autowired secretSessionManager and sets the static one in KubernetesV2Utils like this:

@Component
public class StaticSecretSessionManagerInitializer {

  @Autowired
  private SecretSessionManager secretSessionManager;

  @PostConstruct
  public void init() {
    KubernetesV2Utils.setStaticSecretSessionManager(secretSessionManager);
  }
}

[KathrynLewis]

As for the specifics in the changes: So far all secrets are being decrypted by autowiring a SecretSessionManager which contains the decrypt methods. This works well in all cases but kubeconfig decryption. The problematic spot is in KubernetesV2Utils, since the methods are all static and since we can't call the autowired SecretSessionManager from a static context, we settled on making the methods non-static.

In most of the places KubernetesV2Utils is used, we could just replace the static calls with an autowired kubernetesV2Utils. The one where this didn't work (and where it probably gets confusing) is in KubernetesV2Service since it's an interface. So there, we use the autowired SecretSessionManager that's already hooked up in KubernetesV2Executor.

[dibyom]

Agree that having Utils in the name is not ideal but that predates the secrets work and fixing the naming should be out of scope for this PR.