Move collector/receiver code to opentelemetry-collector-contrib

[rockdaboot]

Now that the code builds well without CGO, consider moving the collector/receiver code from this repository into opentelemetry-collector-contrib.

Suggestion: receiver/ebpfprofilesreceiver

[florianl]

As the OTel Profiling signal is still considered not stable, this step should postponed until the OTel Profiling signal is declared stable. Without a stable OTel Profiling signal, there will be breaking changes, that might cause issues.

[rockdaboot]

There are already two receivers and several exporters and processor that support profiles. So instability doesn't seem to be a general issue. Maybe you have something specific in mind?

Examples

exporter/coralogixexporter/README.md:| Stability     | [alpha]: profiles   |
exporter/elasticsearchexporter/README.md:| Stability     | [development]: metrics, profiles   |
exporter/fileexporter/README.md:| Stability     | [development]: profiles   |
processor/k8sattributesprocessor/README.md:| Stability     | [development]: profiles   |
processor/resourcedetectionprocessor/README.md:| Stability     | [development]: profiles   |
processor/resourceprocessor/README.md:| Stability     | [development]: profiles   |
processor/transformprocessor/README.md:| Stability     | [development]: profiles   |
receiver/otlpjsonfilereceiver/README.md:| Stability     | [development]: profiles   |
receiver/pprofreceiver/README.md:| Stability     | [development]: profiles   |

[florianl]

I think the significant difference here is, that the components you are referring to, are naming the state of their compatibility to the OTel Profiling signal. As far as I can tell, changes to the OTel Profiling signal does not result in direct changes to the API of these components.

Whereas, the API of all packages in this repository change all the them and everything is considered under development. Before promoting a package in OTel collector contrib, the APIs in this repository should be revisited, the OTel Profiling signal should be declared stable and the tagging of this package should also be revisited to align with OTel.

[rockdaboot]

As far as I can tell, changes to the OTel Profiling signal does not result in direct changes to the API of these components.

I'd say that changes made to the profiles signal directly affect each of them (depends on the change of course) . E.g. the change of moving the lookup tables into dictionary affected nearly all existing code.

But surely any stabilization of the protocol makes things easier to maintain.

[christos68k]

We should avoid slowdowns due to extra reviews required for example while the profiler and signal are still changing. This is also the reason we try to do work in repositories we manage for now assuming we have a choice (e.g. see the recent discussion we had about the tooling to validate profiles).