Add a field for non-config files to AgentRemoteConfig

[evan-bradley]

Summary

When configuring an agent, it may be helpful to provide files to the agent that are specifically designated as files that are related to the agent's configuration, but are not configuration files themselves.

Context

This change could be applicable to any agent, but is currently motivated by the way the Collector works. The Collector allows specifying multiple configuration files passed through its command line arguments, and will merge the resulting files. For example:

otelcol --config=file0.yaml --config=file1.yaml --config=file2.yaml

The Collector also allows specifying pulling in configuration from other sources within config files defined in command line arguments. For example, say file0.yaml above contains the following line:

rules: ${file:ruleset.yaml}

The contents of ruleset.yaml would be substituted into the contents of file0.yaml before the full configuration is parsed by the Collector.

If we want to provide multiple files to the Collector through the command line, but also provide files that are read inside of the Collector's configuration files, we would need to specify the difference between files that are top-level configuration and those that are supplementary to configuration. This could include config fragments as above, but also other files such as certificates, binary files, etc. that may be read by the Collector on startup.

Approaches

Add a new field in ServerToAgent

We could add another AgentRemoteConfig-typed field on ServerToAgent named remote_supplementary_config or similar that contains files intended to aid those in remote_config.

Add a new field in AgentRemoteConfig

We could add another list of files in AgentRemoteConfig that contains supplementary configuration files.

Add a new field in AgentConfigFile that specifies the role of a file

We could add another string field, e.g. config_type on AgentConfigFile that specifies how the server intends for the file to be used by the agent, and rely on semantic conventions for what these types mean. This would be the most flexible approach, but would also require the most processing by the agent.

Alternatives

Using PackagesAvailable to provide supplementary files

We could realistically offer supplementary files as packages, but this would be out-of-band for configuration and would likely be a complicated flow.

Utilize the MIME type of config files

We could alter the MIME type of config files, such as adding a parameter, to include OpAMP-specific information that indicates to the agent how a file should be used. This would also be a flexible option, but would need careful consideration to ensure that the OpAMP annotations don't cause unintended conflicts.

[tigrannajaryan]

Discuss in workgroup meeting and the consensus seems to be that we want to "Add a new field in AgentConfigFile that specifies the role of a file".

Something like this:

message AgentConfigFile {
    // Config file or section body. The content, format and encoding depends on the Agent
    // type. The content_type field may optionally describe the MIME type of the body.
    bytes body = 1;

    // Optional MIME Content-Type that describes what's in the body field, for
    // example "text/yaml".
    string content_type = 2;

    // Optional role of the file. The values and their semantics are Agent-type specific.
    string file_role = 3;
}