Use stable network attributes

[avy252004]

Description

This PR updates the "use of stable network attributes from deprecated ones" for the tcp_input and udp_input operators to reflect the migration from deprecated net.* attributes to the stable network.* semantic conventions.

When the StanzaUseStableNetworkAttributesFeatureGate configuration is enabled, users can now opt-in to the stable attributes via a new feature flag.

When the feature flag is enabled, the following attributes are replaced:

Deprecated	Stable Replacement
net.transport	network.transport ("tcp" / "udp")
net.peer.ip	network.peer.address
net.peer.port	network.peer.port
net.host.ip	network.local.address
net.host.port	network.local.port

Please note that net.peer.name and net.host.name are being dropped and do not have stable replacements under the new feature flag.

• Why: The stable semantic conventions currently lack a generic, socket-level equivalent for reverse-DNS hostnames. The closest existing attributes (client.address and server.address) are HTTP-flavored and require making assumptions about which side of the socket is the "client" versus the "server". Such assumptions we cannot safely make for TCP/UDP inputs.
• Effect: When the stanza.useStableNetworkAttributes feature flag is enabled, these two attributes will no longer be emitted. Users relying on these attributes for reverse-DNS hostname resolution will need to account for their absence in downstream processing.

Link to tracking issue

Fixes #49051

Testing

setStableNetworkAttributesGate function added to both tcp/udp_test.go files.

Documentation

pkg/stanza/documentation.md changed and added the
Added details for stanza.useStableNetworkAttributes in the relevant operator READMEs / feature flag registry.

Authorship

• I, a human, wrote this pull request description myself.

[github-actions]

Welcome, contributor! Thank you for your contribution to opentelemetry-collector-contrib.

Important reminders:

• Read our Contributing Guidelines.
• Sign the CLA if you haven't already.
• First-time contributors should have at most one PR not marked as draft until their first PR is merged.
• If your change isn't one of our priority components, reviews may take more time.
• Give reviewers at least a few days before pinging them for feedback.
• If you need help or struggle to move your PR forward:
  • Ask questions regarding general setup, development process, or contributor etiquette in #opentelemetry-new-contributors.
  • Raise technical or Collector-specific questions in #otel-collector-dev or a Collector SIG meeting.