Introduce CA cross-references to peer and orderer CRD specs

[jkneubuh]

When completing the bootstrap TLS node enrollments, Peer and Orderer CRD specs must include a reference to a CA by:

• URL (host + port)
• TLS certificate

These values are readily available in the ca connection-profile configmap, but this imposes some difficulty when constructing networks:

• The CAs must be up / running before the connection profile is generated.
• The connection profiles need to be "mined" for TLS certs and URLs, then string-substituted into the peer/orderer CRDs.

This means that the system constructing a network (Ansible, bash, FoC, etc.) needs to:

1. launch the CAs, wait for them to come up
2. pull connection-profiles, mining the Ingress URLs and TLS certs
3. inject CA URLs and certs into the peer/orderer CRDs

This dynamic substitution and dependency ordering is too hard, annoying (at best), and not required.

Update the peer and orderer CRD specs with the ability to reference a CA by k8s metadata.name, rather than by explicit URL. When specified by name, the operator should defer the construction of peers and orderers until the CA is ready, and substitute the URL/certs dynamically when running bootstrap node enrollments with the CA.

With this update, the sequence of constructing a network of peers, orderers, and CAs can be reduced to a single kubectl apply command, applying en masse all resources required for the network.

Stylistically this should look similar to the k8s "reference" attributes (e.g. secretRef) when specifying relationships between k8s resources. For instance, the following peer spec:

spec:
  secret:
    enrollment:
      component:
        caname: ca
        cahost: "test-network-org1-ca-ca.${INGRESS_DOMAIN}"
        caport: "443"
        catls:
          cacert: "${ORG1_CA_CERT}" 

would be replaced by:

spec:
  secret:
    enrollment:
      component:
        caReference:
          name: org0-ca
          caname: ca           (ca or tls)

With the latter config stanza, the peers and CAs can be constructed simultaneously, with no template / variable substitution required by the application developer. The operator will need to sort out the correct ordering and string substitution behind the scenes.

[jkneubuh]

Hi @jmcshane

This feature will help significantly with #15. Rather: it will remove the bootstrap and need to spin up CAs to "ready and resolving via ingress" before peers and orderers can be applied to k8s. Also, it's not "right" that the initial node enrollments / registrations are going over ingress - the operator can and should run the registration/enrollments directly on the kube-internal network, hitting the CA Services directly.

No need to wait for DNS!