Definition import: allow for arbitrary (and pluggable) sources

[michaelklishin]

Proposed Changes

This makes the definition import mechanism generic and pluggable
(think peer discovery mechanisms) and not tied to a local file
or directory of files. This can be particularly convenient in environments
where running RabbitMQ in a container is the preferred or the only option,
such as GitLab or GitHub service containers used in integration tests.
See docker-library/rabbitmq#508 for some background on this.

The classic local filesystem source is still supported
using the same traditional configuration key, load_definitions.

Configuration schema follows peer discovery in spirit:

• definitions.import_backend configures the mechanism to use,
  which can be a module provided by a plugin
• definitions.* keys can be defined by plugins and contain any
  keys a specific mechanism needs

For example, the classic local filesystem source can now be
configured like this:

definitions.import_backend = local_filesystem
definitions.local.path = /path/to/definitions.d/definition.json

definitions.import_backend = https
definitions.https.url = https://hostname/path/to/definitions.json

definitions.tls.versions.1 = tlsv1.2
definitions.tls.log_level   = error

definitions.tls.ciphers.1  = ECDHE-ECDSA-AES256-GCM-SHA384
definitions.tls.ciphers.2  = ECDHE-RSA-AES256-GCM-SHA384
definitions.tls.ciphers.3  = ECDH-ECDSA-AES256-GCM-SHA384
definitions.tls.ciphers.4  = ECDH-RSA-AES256-GCM-SHA384
definitions.tls.ciphers.5  = DHE-RSA-AES256-GCM-SHA384
definitions.tls.ciphers.6  = DHE-DSS-AES256-GCM-SHA384
definitions.tls.ciphers.7  = ECDHE-ECDSA-AES128-GCM-SHA256
definitions.tls.ciphers.8  = ECDHE-RSA-AES128-GCM-SHA256
definitions.tls.ciphers.9  = ECDH-ECDSA-AES128-GCM-SHA256
definitions.tls.ciphers.10 = ECDH-RSA-AES128-GCM-SHA256
definitions.tls.ciphers.11 = DHE-RSA-AES128-GCM-SHA256
definitions.tls.ciphers.12 = DHE-DSS-AES128-GCM-SHA256

HTTPS may require additional configuration keys related to TLS/x.509
peer verification. Such extra keys will be added as the need for them
becomes evident.

Types of Changes

• Bug fix (non-breaking change which fixes issue #NNNN)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause an observable behavior change in existing systems)
• Documentation improvements (corrections, new content, etc)
• Cosmetic change (whitespace, formatting, etc)

Checklist

Put an x in the boxes that apply. You can also fill these out after creating
the PR. If you're unsure about any of them, don't hesitate to ask on the
mailing list. We're here to help! This is simply a reminder of what we are
going to look for before merging your code.

• I have read the CONTRIBUTING.md document
• I have signed the CA (see https://cla.pivotal.io/sign/rabbitmq)
• All tests pass locally with my changes
• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation (if appropriate)
• Any dependent changes have been merged and published in related repositories

Further Comments

References #3249.

[michaelklishin]

@Mergifyio backport v3.9.x

[mergify]

Command backport v3.9.x: success

Backports have been created

• #3317 Definition import: allow for arbitrary (and pluggable) sources (backport #3311) has been created for branch v3.9.x