Clearly separate Config and Settings terms used in struct names throughout the codebase

[dmitryax]

Currently, we use the Config term for collector configuration as a whole and parts of it defined for receivers/processors/exporters/extensions. Examples:

• otelcol.Config
• component.Config
• otlpexporter.Config

But for unmarshalling some deeper parts of the user config, we use Settings structs, for example:

• exporterhelper.QueueSettings
• configgrpc.GRPCClientSettings
• configtls.TLSSetting

At the same time service/telemetry package still uses Config, e.g. MetricsConfig, LogsSamplingConfig, and TracesConfig.

The suggestion is to use Config term for all the structs used to unmarshal any parts of the YAML config provided by users. We will keep Settings only for structs that are populated programmatically, like:

• component.TelemetrySettings
• component.ReceiverSettings

[bogdandrutu]

I think we should start working on this, because we cannot delay until the stability.

[atoulme]

List of renames:

• [configgrpc] Deprecate GRPCClientSettings, use ClientConfig instead #9402
• [configgrpc] Deprecate GRPCServerSettings, use ServerConfig instead #9403
• [confighttp] Deprecate HTTPClientSettings, use HTTPClientConfig instead #9404
• [confighttp] Deprecate HTTPServerSettings, use HTTPServerConfig instead #9405
• [config/confighttp] Deprecate CORSSettings, use CORSConfig instead #9392
• [exporterhelper] Deprecate QueueSettings, use QueueConfig instead #9393 - on hold, might be part of bigger refactor
• [exporterhelper] Deprecate TimeoutSettings, use TimeoutConfig instead #9391 - on hold, might be part of bigger refactor
• [scraperhelper] Deprecate ScraperControllerSettings, use ControllerConfig instead #9401