comp/trace: wrap pkg/trace/agent as a component

[darccio]

What does this PR do?

Introduce a wrapper for pkg/trace/agent as a component. Important things to know:

• Almost all original agent's code is still in pkg/trace/agent. Some bits have been moved mainly to comp/trace/agent/agent.go, to encapsulate them as part of the agent's lifecycle.
• The one big exception is cmd/trace-agent/subcommands/run/run.go. Now it lives inside the component, as it contains logic to start several non-components that the agent requires. They are potential next candidates to become components.

For future reference, the gist about creating components (at least wrappers like this one) is:

• You need to think of components like a restaurant, it has providers that user required by multiple parts of our component (internal code or other components) and it has three phases: setup, start & stop.
• Setup is fulfilled using a provider, a function encapsulated in a fx.Module and annotated with fx.Provide, and the values/components provided by other providers. The function must return a value matching the exported Component interface in your package. It can be an empty interface.
• Components can require other provided components and supplied values. Defined in the dependencies struct, that must embed fx.In type,the provider function must receive this struct as argument.
• Start is done through an unexported method start registered as a lifecycle hook. Beware of the provided context, as it has a timeout. Don't use it for any long-living code, and also you must not block inside this block.
• Stop is done in the same fashion as start, but the method is called stop. The same conditions apply regarding the provided context.
• If your component must handle signals to interrupt the component, use the injected fx.Shutdowner when catching a signal that means you need to stop.

Additional Notes

• It was not possible to test the command line parsing as now we use fxutil.Run instead of fxutil.OneShot.
• Make sure you have pyinvoke installed. You need to run inv lint-components --fix before pushing, so you can avoid a failing CI.

Possible Drawbacks / Trade-offs

• Introducing possible bugs due to unexpected changes in the processing of the configuration or the altered execution order of some parts (like CPU & memory profiling), or not using the provided context when running as Windows service.

Describe how to test/QA your changes

• Run it in testbed environment.
• Dogfood it in local.

Reviewer's Checklist

• If known, an appropriate milestone has been selected; otherwise the Triage milestone is set.
• Use the major_change label if your change either has a major impact on the code base, is impacting multiple teams or is changing important well-established internals of the Agent. This label will be use during QA to make sure each team pay extra attention to the changed behavior. For any customer facing change use a releasenote.
• A release note has been added or the changelog/no-changelog label has been applied.
• Changed code has automated tests for its functionality.
• Adequate QA/testing plan information is provided if the qa/skip-qa label is not applied.
• At least one team/.. label has been applied, indicating the team(s) that should QA this change.
• If applicable, docs team has been notified or an issue has been opened on the documentation repo.
• If applicable, the need-change/operator and need-change/helm labels have been applied.
• If applicable, the k8s/<min-version> label, indicating the lowest Kubernetes version compatible with this feature.
• If applicable, the config template has been updated.

[bits-bot]

All committers have signed the CLA.

[darccio]

Ready for review, but probably tests will fail. I'll fix them tomorrow.

[katiehockman]

Overall, looks good. Just a few minor comments.

Can you add more details to the PR description, in addition to filling out the sections in the existing template? I feel that using the components framework is pretty nuanced, and it would be very helpful to have more details around what decision decisions were made here, what shared components the trace-agent is now using, which it isn't, future work planned, etc.

[ogaca-dd]

LGTM but I think not returning a nil component is important.

[chouquette]

LGTM for agent-platform