Enhance the management schema to support service listeners with multiple addresses

[ted-ross]

In order to support the coming MultiKeyListener capability in the Skupper control-plane, changes need to be made to the router's management schema to support the new capability.

MultiKeyListener allows service listeners (TcpListener) to be configured with multiple addresses (routing keys) and a strategy by which to choose which address to use for a given service connection.

This issue shall track the management schema changes.

[ted-ross]

Proposed solution:

Modify the TcpListener entity by adding a multi-address strategy field and any additional fields needed to configure that strategy. This field will default to "none", in which case the listener will behave as it did in the past, using the address field as the single address for the listener.

If the multi-address strategy field is not "none", the address field shall be ignored and addresses will be configured via the new entity described below.

Add a new entity type called ListenerAddress containing the following fields:

• address (string)
• value (integer)
• listenerRef (string)

The listenerRef field indicates which service listener the address belongs to. The address field holds the routing key. The value field contains a strategy-specific numeric value (priority, etc.).

In the future, more strategy-specific fields may be added to this new entity type.

Rationale:

Reasons for choosing to separate addresses into separate entities:

• Avoids needing to use structured (JSON) values in entity attributes.
• Avoids requiring the listener code to reconcile the entire list upon changes. Handling changes one address at a time is algorithmically simpler.