Validate tracer blob reproducibility in CI

[athre0z]

Problem

We are currently committing our eBPF tracer blobs into version control to easily allow pulling in the profiler's code as a library in other Go applications. While this is a bit of a hack, it is consistent with what other OTel projects do with generated resources such as protoc generated code. One issue with this approach, however, is that we rely on PR authors to also update the tracer blobs whenever they change BPF code.

Proposed solution

To ensure that people cannot forget to update the blobs or sneak in changes that aren't reflected in the source files they change along with that into our tracer binaries, we should:

• Encourage users to build the tracers with our future builder image
• Add a CI workflow that builds the tracers and ensures that they are byte-by-byte equivalent to what is being committed

We have already verified that the tracer executable build itself is reproducible even when cross-compiling as long as the same toolchain is being used.

Alternatives

Move away from committing tracers into VC

We could stop committing our tracers into VC, forcing downstream "profiling agent as a library" consumers to use this repository as a submodule (or otherwise clone the repo) and build the tracers themselves, passing in the blob in the Tracer constructor.

[rockdaboot]

Move away from committing tracers into VC

If we are going to add OTEL receiver/collector code (so far it looks like every stakeholder wants it), we want to support the ocb tool. This tool works best in a pure Go environment.

I'd really prefer the suggested CI workflow. We possibly can extend it to add the tracer blobs to the PR, whenever the CI blobs are different from the blobs in the target branch.