<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
Adds a feature gate that allows starting the Collector without running
any pipelines. This will mainly be used for OpAMP, where the Collector
may need to be started with only extensions
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
Builds on
https://github.com/open-telemetry/opentelemetry-collector/pull/12224 and
starts the move of config validation from component to confmap. We can
keep this in `xconfmap` while we determine whether to add the ability to
validate using struct field tags.
I think this has the following advantages:
1. Everything configuration-related is now in confmap instead of split
between confmap and component.
2. We can share things like the mapstructure tag and config key
separator as constants between unmarshaling and validation without
creating dependencies between confmap and component.
~The one uncertainty this creates is what to do with `component.Config`,
which would now be used as a thin alias for `any` without any meaningful
usage in component.~
<!-- Issue number if applicable -->
#### Link to tracking issue
Fixes
https://github.com/open-telemetry/opentelemetry-collector/issues/11524
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
Follow-up to
https://github.com/open-telemetry/opentelemetry-collector/pull/12108.
This calls `component.ValidateConfig` on `otelcol.Config`, which causes
`Validate` to be recursively called on all eligible structs in the
config.
This has the following benefits:
1. `Validate` will now automatically be called instead of config structs
needing to call it on member structs.
2. Paths to the exact key that caused a validation error in the config
are now consistently printed.
3. If there are multiple errors in the config, they are now all returned
to the user instead of just the first error encountered.
#### Description
[gofumpt](https://golangci-lint.run/usage/linters/#gofumpt) is a
stricter format than gofmt, while being backwards compatible.
Signed-off-by: Matthieu MOREL <matthieu.morel35@gmail.com>
Co-authored-by: Alex Boten <223565+codeboten@users.noreply.github.com>
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
This hides profiles support behind a feature gate, so folks have to
enable them explicitly to be able to use them.
**Description:**
- Adds `component.MustNewType` to create a type. This function panics if
the type has invalid characters. Add similar functions
`component.MustNewID` and `component.MustNewIDWithName`.
- Adds `component.Type.String` to recover the string
- Use `component.MustNewType`, `component.MustNewID`,
`component.MustNewIDWithName` and `component.Type.String` everywhere in
this codebase. To do this I changed `component.Type` into an opaque
struct and checked for compile-time errors.
Some notes:
1. All components currently on core and contrib follow this rule. This
is still breaking for other components.
2. A future PR will change this into a struct, to actually validate this
(right now you can just do `component.Type("anything")` to bypass
validation). I want to do this in two steps to avoid breaking contrib
tests: we first introduce this function, and after that we change into a
struct.
**Link to tracking Issue:** Updates #9208