Allow remote configuration of an agent's non-identifying attributes

[BinaryFissionGames]

In the AgentToServer message, the AgentDescription portion gives a list of non-identifying attributes. These attributes can help to narrow down an agent and add useful context, but currently cannot be remotely configured.

If we can remotely configure these attributes, we can better identify the agent remotely. It also allows extra data to be associated with and carried by the agent as it connects to different OpAMP capable systems without needing manual intervention on the monitored system.

Use Case

To remotely configure attributes to associate with the agent to any OpAMP server.

Implementation

In order to remotely configure the non-identifying attributes, a new field would be added somewhere in the the ServerToAgent message. For instance, we could add a new field ServerToAgent.remote_description with a new message type, containing a new_non_identifying_attributes field:

message RemoteAgentDescription {
  repeated KeyValue new_non_identifying_attributes = 1;
}

As well as adding a new capability, AgentCapabilities_AcceptsRemoteAgentDescription.

The agent should update its non_identifying_attributes if new_non_identifying_attributes is specified, and report any further AgentDescription messages with them. new_non_identifying_attributes is the full set of non_identifying_attributes that should be present from now on on the agent. No merging is performed, and the agent just takes the set of new attributes.

Alternative approaches

1. We could alternatively leave this as something agent-specific on how to configure. There is precedent however with the instance_uid that the fields that are in OpAMP should be configurable in a well defined way through the protocol itself.

2. Instead, we could modify the AgentRemoteConfig, adding the new non-identifying attributes there instead:

message AgentRemoteConfig {
    AgentConfigMap config = 1;
    bytes config_hash = 2;
    repeated KeyValue new_non_identifying_attributes = 3;
}

The disadvantage here is that agents that want to accept remote config must also accept changes to their non-identifying attributes. The advantage is that we wouldn't need a whole new message type in order to have this capability.