Adds Profiles Signal

[petethepig]

Description

This is a PR that adds profiling support to collector. Relevant links:

• OTEP 239 — Introduces Profiling Data Model v2

State of this PR

This is currently work in progress. The code compiles and tests pass, however I'm planning to split this one into smaller chunks to simplify the review process.

TODOs:

• rebase off of [DO NOT MERGE] Showcase PR: Add profiling pdata #10109
• double check that I added profiling support to all of the components
• add instructions on how to test this end-to-end
• make sure I properly marked profiles as experimental everywhere

Testing

Workflow I use to test this right now:

• Run make otelcorecol to verify that collector compiles
• Run ./bin/otelcorecol_darwin_arm64 --config=file:tmp/config.yaml (config is here)
• Run curl -i -X POST http://localhost:4318/v1experimental/profiles -H 'Content-Type: application/json' -d @profile.json (profile.json is here)
• ^ This prints the profile in text form

---

My plan is to have an end-to-end pipeline where you can run collector with an example client and example backend to test the whole pipeline. I did this with an earlier version of this PR, but haven't updated it yet. Will do this soon and update PR descriptions with instructions on how to run it.

[mx-psi]

It's great to have this PR to have a full picture of what support for profiles entails, thanks for moving this along!

As we discussed on the last Collector SIG, when we work on adding profiles support, we need to add this in a way that is mindful of the Collector 1.0 effort and can separate experimental APIs related to profiling from the ones we intend to stabilize now. How to do this is an open question (see #9209 for related discussion that we may need to address when doing this), and I am happy to help here to move this along.

In general, the approach I want to explore first is to put profiling related interfaces, structs and options into separate modules. If something needs to be on the same module as 1.0 stuff (I currently don't see any blockers like this), then we'll need to see if we can refactor things to make it go away or deal with it in the way proposed in #9209.