SPIRE bundle endpoint server should be configurable in terms of profile

[evan2645]

When configuring federation in SPIRE Server, remote bundle endpoint servers are configured in terms of what profile they are using (i.e. https_web or https_spiffe). This is in contrast to SPIRE Server's bundle endpoint server, the configuration of which takes only address/port and an optional ACME config. If ACME is configured, the bundle endpoint server uses the https_web profile, and if not then it uses the https_spiffe profile.

This distinction isn't documented anywhere, and it is also confusing to users who now have to choose a "profile" when they didn't have to originally. Instead, SPIRE Server's bundle endpoint server should be configurable in terms of profile the same way that the client is, and the ACME configurables should simply be a part of the https_web profile configuration.

Propose then implement a new configuration shape for the bundle endpoint server that is more closely aligned with the client configuration and the specification terminology

[evan2645]

Here is the current configuration shape for the bundle endpoint server

server {
    .
    .
    .
    federation {
        bundle_endpoint {
            address = "0.0.0.0"
            port = 8443
            acme {
                domain_name = "example.org"
                email = "mail@example.org"
            }
            refresh_hint = "10m"
        }
    }
}

Here is the proposed shape that better aligns with the spec, and with the federates_with configuration stanzas:

server {
    .
    .
    .
    federation {
        bundle_endpoint {
            address = "0.0.0.0"
            port = 8443
            refresh_hint = "10m"

            profile "https_web" {
                acme {
                    domain_name = "example.org"
                    email = "mail@example.org"
                }

                static_serving_cert_path = "/path/to/cert.crt"
                static_serving_cert_key_path = "/path/to/cert.key"
            }

            profile "https_spiffe" {}
        }
    }
}

Where only one profile block can be specified, and either acme or (static_serving_cert_path and static_serving_cert_key_path) are required if https_web profile is selected.

Support for static_serving_cert_path and friends is not currently implemented, and is not required to be implemented for the purpose of this issue, but I wanted to illustrate where it would land with the new config shape since we're likely to take that as a feature at some point in the future.

Back compat

To migrate, we allow either a single profile to be specified, acme to be specified, or nothing to be specified. All three conditions are mutually exclusive. If acme is specified, it implies profile "https_web" with the provided acme config block. If nothing is specified, it implies profile "https_spiffe".

Whenever a profile is not specified and we imply its existence through back compat config, we should log a warning and guide the user to configure the correct profile.