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 85.13011% with 40 lines in your changes missing coverage. Please review.
✅ Project coverage is 82.9%. Comparing base (7214567) to head (3e1cc95).

Files with missing lines	Patch %	Lines
opentelemetry-context/src/process_context/linux.rs	83.6%	36 Missing ⚠️
opentelemetry-context/src/process_context/mod.rs	91.8%	4 Missing ⚠️

Additional details and impacted files

@@          Coverage Diff           @@
##            main   #3460    +/-   ##
======================================
  Coverage   82.8%   82.9%            
======================================
  Files        130     132     +2     
  Lines      27289   27558   +269     
======================================
+ Hits       22618   22851   +233     
- Misses      4671    4707    +36     

☔ 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!

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: scottgerring / name: Scott Gerring (377eda6, 3bdd25c, 3e1cc95, 7085416, a5acfd0, c007c7a, c6ed75d, d62ab33, 82ea43d)

[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 ?

[scottgerring]

/easycla

[lalitb]

@scottgerring - Thanks for calling out the placement tradeoff in the PR description. I agree that the process-context proto message itself is related to opentelemetry-proto, but I am less sure about adding publish/unpublish there as the public API.

That API owns process-global runtime behavior, Linux mmap/memfd/prctl details, update semantics, and SDK Resource lifecycle. With thread-context sharing also being discussed, this area may grow beyond just process-level context. Option 2 from the description, a small dedicated context-sharing crate, feels cleaner to me than expanding opentelemetry-proto into this runtime surface.

One related question: should process_context.proto first live in open-telemetry/opentelemetry-proto? From what I can tell, this PR adds the proto locally in opentelemetry-rust rather than consuming it from the upstream proto definitions. If the message shape is still part of the OTEP/spec work, I would prefer not to make opentelemetry-rust
look like the canonical owner of that proto.

I do not want to block this PR only on crate placement, but I think it is worth aligning on the intended long-term home before this becomes a public API we have to support.

[scottgerring]

Hey @lalitb thanks for taking a look!

Option 2 from the description, a small dedicated context-sharing crate, feels cleaner to me than expanding opentelemetry-proto into this runtime surface.

Agreed 100% it is weird in the proto repo! I think there's an argument to be made it could go in opentelemetry-sdk, but for that we need to fix the proto<->sdk coupling issue. I have a local branch that does that but that's also a big piece of work in and of itself. What's your feeling on fixing that and putting it in the sdk vs. new crate?

P.S. i've added two commits on the top to show what it looks like as a standalone crate.

One related question: should process_context.proto first live in open-telemetry/opentelemetry-proto? From what I can tell, this PR adds the proto locally in opentelemetry-rust rather than consuming it from the upstream proto definitions. If the message shape is still part of the OTEP/spec work, I would prefer not to make opentelemetry-rust look like the canonical owner of that proto.

There's some discussion ongoing about this but it does look like it's going to end up in the proto repo. I think in the meantime we could get it going with a local copy with heavy caveats ("this is going to move!!1") - what do you think?