Refactor CA to plugins

[jakubdyszkiewicz]

Summary

Mesh model

Mesh model changed from

type: Mesh
name: default
mtls:
  enabled: true
  ca:
    builtin: {}
---
type: Mesh
name: default
mtls:
  enabled: true
  ca:
    provided: {}

to

type: Mesh
name: default
mtls:
  enabledBackend: ca-1 # enabled is gone, if this is present mTLS is enabled with backend of choice. If this is absent mTLS is off.
  backends:
  - name: ca-1
    type: builtin
  - name: ca-2
    type: provided
    config:
      cert:
        secret: sec-1
      key:
        secret: sec-2

Config can be anything (google.protobuf.Struct) therefore each plugin has to validate it's backend.

This also means that there might be multiple backends of the same type in one Mesh.

Provided CA

In case of provided, we no longer have to upload cert+key with kumactl manage ca provided. Instead you use Secret Management API to upload cert as a secret and reference it in the config.
Therefore kumactl manage ca provided (whole manage subcommand) is gone as well as webservice to handle it.
We no longer have to validate if there is only one cert since config implies that there is only one.

Data Source

I introduced a concept of DataSource. When defining a cert and key for provided

  - name: ca-2
    type: provided
    config:
      cert:
        secret: sec-1
      key:
        secret: sec-2

you can also provide the cert and key via file or with just inline bytes.

  - name: ca-2
    type: provided
    config:
      cert:
        inline: BASE64Bytes
      key:
        file: /opt/cert.pem

It was easy to implement and it's great for testing and may be also used on production if someone prefers to store certs in files.

Tests

Builtin CA was lacking in tests, so I added them. Tests for provided had to be rewritten.

I'm sorry about the volume of this PR. It was all tangled up and was really hard to split into multiple PRs and keep the functionality working.

[lobkovilya]

Maybe makes sense to write its type also, like builtin/ca-1? Because that change makes kumactl get meshes less informative

[jakubdyszkiewicz]

Question to @subnetmarco how should kumactl get meshes look like?
Right now given

type: Mesh
name: default
mtls:
  enabledBackend: ca-1
  backends:
  - name: ca-1
    type: builtin
  - name: ca-2
    type: provided
    config: ...

I print

NAME      mTLS  METRICS  LOGGING  TRACING
default   ca-1  off      off      off

If enabledBackend is not specified, I print off.

Ilya's argument is that it less information because previously we've seen the type (only the type since it was 1 CA per mesh)

[jakubdyszkiewicz]

We came into conclusion with Marco that we will only display current backend with a format like you proposed which is type/name.
I will refactor also others in the same way when I unify the config for Tracing/Logging/Metrics.