Allow preconfiguration of a bundle path in SPIRE server federation config

Currently, setting up static SPIRE server federation relationships requires the administrators to share the bundles between federated SPIRE servers to bootstrap trust, at which point the federation subsystem begins dynamically pooling peers for their latest bundle. Said sharing looks like this: spire-server bundle set -id spiffe://my.trust.domain, and then an optional -path argument to allow the bundle to be loaded from the filesystem. If the -path argument is not set, the bundle is loaded from stdin.

This is an unfortunate pattern, because it prevents users from being able to automatically and declaratively deploy SPIRE servers. It requires the administrator to already have the bundle from the federated trust domain, and requires imperative commands to be executed.

It would be much better for declarative deployments to be able to set the filesystem path of the bundle when configuring the SPIRE server, like this:

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"
                }
            }
        }
        federates_with "domain1.test" {
            bundle_endpoint_url = "https://1.2.3.4:8443"
            bundle_endpoint_profile "https_web" {}
            bootstrap_bundle_path = "/var/path/to/my/bundle.pem"
        }
        federates_with "domain2.test" {
            bundle_endpoint_url = "https://5.6.7.8:8443"
            bundle_endpoint_profile "https_spiffe" {
                endpoint_spiffe_id = "spiffe://domain2.test/beserver"
            }
            bootstrap_bundle_path = "/var/path/to/my/other/bundle.pem"
        }
    }
}

The bootstrap_bundle_path could then be watched and reloaded on change, allowing administrators to declaratively configure SPIRE server instances and then load bundles in via an asynchronous method. It would be particularly useful in Kubernetes, where the Notifier plugin could be used to publish bundles to a configmap that is then mounted into a federated SPIRE server.

While an attacker gaining access to the SPIRE server's filesystem and manipulating the path could represent a threat, compromising the filesystem of the SPIRE server would alredy be a catastrophic breach as it stands today, and I don't believe that this has a meaningful impact on the security posture of the SPIRE server architecture.