Add OpenTelemetry metrics support with semantic conventions

[Zerpet]

This pull request introduces OpenTelemetry (OTEL) metrics support to the RabbitMQ AMQP 1.0 Go client, allowing users to collect, export, and observe metrics related to connections, publishers, consumers, and message flows. The changes include a new OTEL metrics example, enhancements to the environment and connection APIs for metrics configuration, and integration of metrics collection throughout the connection and consumer lifecycles.

OTEL Metrics Integration:

• Added a new example in docs/examples/otel_metrics/ demonstrating how to configure and use OTEL metrics with a stdout exporter, including a go.mod file and a comprehensive main.go walkthrough. [1] [2]
• Updated the main module go.mod to require OpenTelemetry dependencies and updated other dependencies to support metrics collection. [1] [2]

Environment and API Enhancements:

• Refactored Environment and ClusterEnvironment constructors to accept functional options, including WithMetricsCollector and WithStrategy, making metrics configuration flexible and extensible. [1] [2] [3] [4]
• Updated example documentation to reflect the new functional options pattern for environment creation and configuration.

Connection and Consumer Metrics Instrumentation:

• Instrumented connection lifecycle: metrics are now recorded when connections are opened and closed, with support for OTEL semantic conventions (e.g., server address and port). [1] [2] [3] [4] [5]
• Instrumented consumer lifecycle and message disposition: metrics are recorded for consumer open/close events, message consumption, and message disposition (accepted, discarded, requeued), with context attributes for OTEL. [1] [2] [3] [4] [5]

These changes provide a robust foundation for observability and monitoring, making it easier to integrate the client with modern telemetry systems.

Most important changes:

OTEL Metrics Example and Dependencies

• Added a new OTEL metrics example with main.go and go.mod in docs/examples/otel_metrics/ to demonstrate metrics collection and export. [1] [2]
• Updated main go.mod to include OTEL dependencies and update related modules. [1] [2]

Environment and API Improvements

• Refactored Environment and ClusterEnvironment constructors to use functional options (WithMetricsCollector, WithStrategy), making metrics and strategy configuration more flexible. Deprecated the old strategy-based constructor. [1] [2] [3] [4]

Connection Metrics Instrumentation

• Added metrics collection to connection open/close events, including OTEL semantic conventions for server address and port. [1] [2] [3] [4] [5]

Consumer and Message Metrics Instrumentation

• Integrated metrics collection into consumer open/close, message consumption, and message disposition events, with OTEL context attributes. [1] [2] [3] [4] [5]

Documentation and Example Updates

• Updated example code and comments to illustrate the new metrics and environment configuration patterns.
• Added a document with implementation guidelines to serve as reference for metric implementation. This document can be used by other agents in other client libraries. This will help to have consistency among all the AMQP client implementations.

Closes #9

[Zerpet]

@Gsantomaggio in theory, we are in the code freeze period. I'll let you decide if you want to squeeze this feature in Feb release, or include in March release.

[Gsantomaggio]

Thank you, @Zerpet. I will wait for the next release.

[Gsantomaggio]

Thanks @Zerpet

Can we use the same .NET client names and metrics

[Zerpet]

Thanks @Zerpet

Can we use the same .NET client names and metrics

We have mostly the same metrics. I renamed consumed.* to consumed_* to match .NET, same for published.*. In this client is challenging to have "duration" metrics, like in .NET, because the message handler model is different. In .NET (like in Java), it uses a function callback. In this client, the users "pull" a message using Receive() and eventually settle the message (accept, reject, etc.); the client library can't observe the message processing, making it challenging to report a "duration" metric accurately.

[Gsantomaggio]

Thanks @Zerpet, we can merge! Great job!