Feature-gate weaver behind optional dev-tools flag to eliminate transitive ring dependency

[pritishnahar95]

Pre-filing checklist

• I searched existing issues and didn't find a duplicate

Component(s)

Rust OTAP dataflow (rust/otap-dataflow/)

Is your feature request related to a problem?

Summary

The weaver crates (weaver_forge, weaver_semconv, weaver_resolved_schema,
weaver_resolver, weaver_common) are regular dependencies of otap-df-core-nodes
and otap-df-otap, used to power the fake_data_generator receiver — a
dev/testing/benchmarking tool for generating synthetic telemetry data. They should
be gated behind an optional feature flag (e.g., dev-tools, included in default
features for backward compatibility) so that production builds can opt out and
avoid weaver's transitive ring dependency.

See #2269 (comment)

Motivation

After #2269 (pluggable crypto providers), the only remaining transitive ring
path within the project's control is through weaver:

Feature-gating weaver would fully eliminate ring from crypto-openssl
production builds (built with --no-default-features).

(opentelemetry-otlp is the other transitive path, but will be removed once the
internal telemetry pipeline refactor is complete — tracked separately.)

Proposed Solution

• crates/core-nodes: Make weaver_* dependencies optional, add dev-tools
  feature flag, gate fake_data_generator module (including its linkme
distributed_slice registration) behind #[cfg(feature = "dev-tools")]
• crates/otap: Move weaver_* from regular dependencies to dev-dependencies
  (only used in tests/pipeline_tests.rs, not in source)
• crates/validation: Move weaver_* from regular dependencies to
  dev-dependencies (only used in #[cfg(test)] in encode_decode.rs); add
  core-nodes dev-dependency with dev-tools feature for test access to
  fake_data_generator
• Root Cargo.toml: Add dev-tools feature forwarding to
  otap-df-core-nodes/dev-tools, include in default features
• No Dockerfile changes needed — it already uses explicit --features (not
  defaults), so dev-tools is excluded from production images unless passed

Alternatives Considered

No response

Additional Context

No response

[lalitb]

(opentelemetry-otlp is the other transitive path, but will be removed once the
internal telemetry pipeline refactor is complete — tracked separately.)

Just to update, I have raised a PR for opentelemetry-otlp to support provider agnostic TLS - open-telemetry/opentelemetry-rust#3423 - so this should be usable once new crate is published.

[lquerel]

@pritishnahar95 I support this change. If the dev-tools feature is not a default feature, we will need to pay attention to the implications for the benchmarking system, which relies on the traffic_gen receiver. In that case, the necessary changes will have to be made in the YAML files and scripts.

[pritishnahar95]

@pritishnahar95 I support this change. If the dev-tools feature is not a default feature, we will need to pay attention to the implications for the benchmarking system, which relies on the traffic_gen receiver. In that case, the necessary changes will have to be made in the YAML files and scripts.

For now, I am ok with keeping dev-tools as a default feature, unless we have major objections to it. The collector can be built with cargo build --no-default-features --features jemalloc,crypto-openssl to ensure no dependencies on ring. @lalitb @drewrelmas what do you think?