Expose a new endpoint for injection in the proxy auto-injector

[alpeb]

Expose a new endpoint in the control plane that performs the proxy injection, given the new stored config (#1999). This will be used by both linkerd install/inject (#2288) and the auto-injector (#2289).

It should receive the resource yaml in the request, and return the injected yaml, or the JSON patch.
A request param should determine the type of the response.
As a followup, this endpoint should take into account the annotations/labels of the namespace and the resource itself for overriding the config (#2287)

[alpeb]

We can provide this as a new endpoint in the controller api, or as part of the auto-injector, in which case we need to lift the current restriction of only installing the auto-injector when --proxy-auto-inject is provided at install time.

[ihcsim]

My thought is to re-use the existing proxy-injector controller, and change the effect of the --proxy-auto-inject flag such that, if enabled, then the admission controller webhook is installed. Otherwise, it only serves the new endpoint.

[klingerf]

👍 to @ihcsim's comment. Originally I was thinking we should add a separate endpoint that's called by both the CLI and the auto-injector, but I think we'll gain a lot by instead forcing the CLI to use the auto-inject endpoint directly (although not by way of the linkerd-proxy-injector Service that the webhook uses -- we'll instead need to expose that endpoint via the public API).

By forcing the CLI to use the auto-inject endpoint, it guarantees that CLI injection and auto-injection will maintain feature parity. We won't be able to add additional functionality to CLI inject without also making that functionality available to auto-inject users.

Also, since auto-inject requires modifications in JSON patch format but the CLI outputs fully-patched YAML, I feel like we'd end up with a lot of conditional formatting logic in an endpoint that provides both formats. Instead, if we only support JSON patch format, the CLI can leverage k8s.io code directly to apply those patches, and we won't need an inject implementation in our codebase that produces fully-patched YAML.

In terms of running an additional pod in non-auto-inject control plane installs, I think it's fine to include the proxy-injector pod to serve the inject endpoint, with a flag to control whether or not it creates the MWC, based on whether auto-inject is enabled or not. We could also investigate moving the proxy-inject container into the linkerd-controller pod, since it would be a required part of all control plane installs. I don't feel too strongly one way or another on that.

[alpeb]

This has been superseded by #2447