Support different format for defaultContext

Is your feature request related to a problem? Please describe.

We have loads of services built on Spring-Boot/Cloud using Consul as the backend for service configuration. Our default setup for services is like this:

spring.cloud.consul.config.prefix=platform-config
spring.cloud.consul.config.defaultContext=common

That is - services will grab configuration from platform-config/<service-name> and platform-config/common.

Under common we typically keep environment specific variables (like DB connection URL, credentials and what-not) as key-value entries in Consul. Those properties are then referenced from application-scoped configuration (service.property.foo: ${shared.property.bar}).

For most services this works fine, but some services uses the YAML format to read configuration. The main reason for using YAML is that the service's configuration would be painful to express in standard .properties (like, nested and dynamic properties).

Services using YAML will typically embed a bootstrap.yml like this:

spring.cloud.consul.config:
  format: YAML
  data-key: application.yml

That is, they expect to find an application.yml in Consul as platform-config/<application-name>/application.yml.

Unfortunately this also means that they will not be able to refer to "global" configuration properties under platform-config/common unless there's also an application.yml there with the expected properties.

Describe the solution you'd like

It would be really useful to be able to specify the format used to read from the defaultContext.

In our case we'd set that to be KEY_VALUE and then allow the service itself decide how to read the service specific configuration from platform-config/<application-name>.

Describe alternatives you've considered

Currently there are really only two options:

1. Enforce the same configuration format across all services. Doable, but it's not really aligned with the way we work (the individual teams owns their services, the platform team manages the common area).
2. Duplicate the key-value entries under common so that they are available in all "formats". This is painful - some team might decide to use data-key: application.yml, another team might do data-key: application.yaml and a third data-key: application.properties (and the PROPERTIES format).

Start by locating the Consul configuration handling for defaultContext, format, and data-key, then inspect the existing configuration-related tests. Define how a separate default-context format should coexist with the service-specific format. Done means shared KEY_VALUE properties can be read from the default context while service configuration continues using its selected format, with coverage for both paths.