feat: Implement process context publishing (OTEP-4719)

[scottgerring]

Summary

Implements the publisher side of OTEP-4719 (Process Context Sharing) behind the process-context feature flag on opentelemetry-proto. This is helpful for signal correlation - and together with the thread context sharing (OTEP-4947), will allow the Rust community to have request-correlated profiling support. This is a linux-only mechanism by design and the API to support it provides a no-op impl for other targets.

On Linux, this publishes SDK resource attributes to a named memory mapping (OTEL_CTX) so external readers (such as the OpenTelemetry eBPF Profiler) can discover process metadata without direct integration or process activity.

This is a precursor for OTEP-4947 which will enable per-thread resource attribution building on top of the process-level mechanism implemented here.

The implementation is adapted from the implementation used in libdatadog, a shared library we use underneath many of our own datadog libraries.

Usage

use opentelemetry_sdk::Resource;

let resource = Resource::builder()
    .with_service_name("my-service")
    .build();

// Publish resource as process context (no-op on non-Linux)
opentelemetry_proto::process_context::publish(&resource);

// Later, during shutdown:
opentelemetry_proto::process_context::unpublish();

Decisions

Why opentelemetry-proto?

I reckon this probably belongs in opentelemetry-sdk, but because opentelemetry-proto depends on that for its transformation layer we can't reference our proto types there (see #3045).

We have options:

1. Publish it from the proto crate
2. Create a new crate just for this (in the future perhaps it would also contain the thread-local context publishing mechanism)
3. Fix Simplify opentelemetry-proto: SDK decoupling, gRPC separation #3045 first, put it in sdk

I'd like to do (3) (and am happy to impl it myself), but as I poked this issue recently and heard nothing back I am hesitant to put it in the dependency path for this.

Publishing mechanism
I've made this explicit - the user must explicitly use this API to publish - look at the updated example code. I'd prefer if this happened automatically, but because each signal stands alone and is provided its own resource, it is difficult to envisage how an automatic publishing mechanism should work. If anyone has any better ideas lmk.

Merge requirement checklist

• CONTRIBUTING guidelines followed
• Unit tests added/updated (if applicable)
• Appropriate CHANGELOG.md files updated for non-trivial, user-facing changes
• Changes in public API reviewed (if applicable)

[codecov]

Codecov Report

❌ Patch coverage is 83.81295% with 45 lines in your changes missing coverage. Please review.
✅ Project coverage is 83.2%. Comparing base (75a0b7e) to head (27cc658).

Files with missing lines	Patch %	Lines
opentelemetry-proto/src/process_context/linux.rs	82.0%	41 Missing ⚠️
opentelemetry-proto/src/process_context/mod.rs	91.8%	4 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##            main   #3460     +/-   ##
=======================================
- Coverage   83.2%   83.2%   -0.1%     
=======================================
  Files        128     130      +2     
  Lines      25086   25364    +278     
=======================================
+ Hits       20896   21125    +229     
- Misses      4190    4239     +49     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[scottgerring]

I've pulled this up to represent the public API, subbing in either a linux-64 or a no-op impl based on the target

[scottgerring]

Makes it easier for testing

[scottgerring]

@cijothomas @lalitb it would be great to get alignment on where this should live (see my idea of the options in the PR text) first!

[yannham]

I wonder if the whole fork business should really be here? I suppose support for languages with a forking runtime isn't really Datadog-specific, but one could also leave that out for a first implementation. I don't really have an opinion myself, just asking.

[scottgerring]

Good catch; this is certainly not a common pattern in Rust! I will remove it.

[yannham]

I also meant the whole pid business in the code. That is, I think we can simplify the code a bit if we don't care about forks (basically removing the pid field and the case Some(handle) => below when pid != getpid()). We would also get away from the whole "memory allocation is UB after a fork" trap: we don't pretend to handle arbitrary forks anymore.

[linux-foundation-easycla]

• ✅ login: scottgerring / name: Scott Gerring (06ea75b, 1099f1b, 1748286, 3729ca7, d3cfb3b, 27cc658)
• ❌ The email address for the commit (27cc658) is not linked to the GitHub account, preventing the EasyCLA check. Consult this Help Article and GitHub Help to resolve. (To view the commit's email address, add .patch at the end of this PR page's URL.) For further assistance with EasyCLA, please submit a support request ticket.

One or more co-authors of this pull request were not found. You must specify co-authors in commit message trailer via:

Co-authored-by: name <email>

Supported Co-authored-by: formats include:

1. Anything <id+login@users.noreply.github.com> - it will locate your GitHub user by id part.
2. Anything <login@users.noreply.github.com> - it will locate your GitHub user by login part.
3. Anything <public-email> - it will locate your GitHub user by public-email part. Note that this email must be made public on Github.
4. Anything <other-email> - it will locate your GitHub user by other-email part but only if that email was used before for any other CLA as a main commit author.
5. login <any-valid-email> - it will locate your GitHub user by login part, note that login part must be at least 3 characters long.

Alternatively, if the co-author should not be included, remove the Co-authored-by: line from the commit message.

Please update your commit message(s) by doing git commit --amend and then git push [--force] and then request re-running CLA check via commenting on this pull request:

/easycla

[scottgerring]

• ✅ login: scottgerring / name: Scott Gerring (06ea75b, 1099f1b, 1748286, 3729ca7, d3cfb3b, 27cc658)
• ❌ The email address for the commit (27cc658) is not linked to the GitHub account, preventing the EasyCLA check. Consult this Help Article and GitHub Help to resolve. (To view the commit's email address, add .patch at the end of this PR page's URL.) For further assistance with EasyCLA, please submit a support request ticket.

One or more co-authors of this pull request were not found. You must specify co-authors in commit message trailer via:

Co-authored-by: name <email>

Supported Co-authored-by: formats include:

1. Anything <id+login@users.noreply.github.com> - it will locate your GitHub user by id part.
2. Anything <login@users.noreply.github.com> - it will locate your GitHub user by login part.
3. Anything <public-email> - it will locate your GitHub user by public-email part. Note that this email must be made public on Github.
4. Anything <other-email> - it will locate your GitHub user by other-email part but only if that email was used before for any other CLA as a main commit author.
5. login <any-valid-email> - it will locate your GitHub user by login part, note that login part must be at least 3 characters long.

Alternatively, if the co-author should not be included, remove the Co-authored-by: line from the commit message.

Please update your commit message(s) by doing git commit --amend and then git push [--force] and then request re-running CLA check via commenting on this pull request:

/easycla

Hey @yannham , do you mind signing the CTA now that i've taken your suggestion ?