[5/8] coordinator: support insecure manifests behind opt-in

[msanft]

Split from #2337 as part of a stacked review series.

Depends on: #2355

This PR wires insecure manifests into the Coordinator behind explicit opt-in:

• manifest helpers for insecure reference values
• Coordinator opt-in gate
• validator registration for insecure manifests
• user API and tests

Closes CON-212

[charludo]

Thanks! Sorry review took so long. I have a couple of comments, see below; the one architectural one I want to get your opinion on is if we should allow mixed manifests. Is that something you actually require? Because if not, then I'd strongly urge to allow either all-secure, or all-insecure manifests, no mix.

[sespiros]

Thanks, I second Charlotte's comment about needing to decide whether we want to allow mixed manifests. My understanding was that we actually do need to do that for the benchmarking use case that triggered this PR series.

If that's the case we should at least close the impersonation gap by adding a per-policy attestation-type binding (which doesn't exist today). An attacker who controls an insecure node can produce an attestation that authenticates as any CC policy in the manifest, because meshapi.NewMeshCert does Policies[hostData] without checking which validator produced the hostData.

For example like:

type PolicyEntry struct {
    SANs                   []string
    WorkloadSecretID       string
    Role                   Role
    AllowedAttestationOIDs []asn1.ObjectIdentifier `json:",omitempty"`
}

[linear-code]

CON-212

[msanft]

the one architectural one I want to get your opinion on is if we should allow mixed manifests. Is that something you actually require?

I've thought about this for some time now, and couldn't think of a use-case we'd need a mixed manifest for. I second your opinion that it should not be allowed then.

[msanft]

ping, this should be ready for another round of review @burgerdev @sespiros @charludo