Adds metrics export using opentelemetry API for notifications queue processing

[romank0]

In order to monitor the listener process it makes sense to export metrics. This PR uses opentelemetry API that allows to export metrics in a generic way if the client opts-in.

I've tested this with two configurations:

1. using ConsoleExporter described in README
2. using OTLP exporter to the DataDog agent (see here for details) using this factory:

class ListenerMeterProviderFactory(MeterProviderFactory):
    def get_meter_provider(self) -> MeterProvider:
        exporter = OTLPMetricExporter(endpoint="localhost:4317", insecure=True)
        reader = PeriodicExportingMetricReader(exporter, export_interval_millis=5000)
        metric_provider = MeterProvider(
            resource=Resource(
                attributes={SERVICE_NAME: "test-service", DEPLOYMENT_ENVIRONMENT: "dev"}
            ),
            metric_readers=[reader],
        )
        return metric_provider

[romank0]

I'm not sure about this being a mandatory dependency. I think this can be changed so that if the user does not opt in the requirement is optional.

[PaulGilmartin]

In order to monitor the listener process it makes sense to export metrics. This PR uses opentelemetry API that allows to export metrics in a generic way if the client opts-in.

I'm not familiar at all with OpenTelemetry. I have a few questions:

• Where is the information exported to?
• How often is it exported?
• What does it look like when exported? Do you have any screen shots or anything?

I'm not 100% sure yet whether or not this should be part of the library itself, but it definitely seems like a cool idea. Hopefully once I know the answers to the above questions, I'll be able to understand better why it should be in the library.

[romank0]

OpenTelemetry is a set of APIs, libraries, agents, and instrumentation that help in generating and managing telemetry data (metrics, logs, and traces) from applications. It is vendor-neutral and can be easily integrated with various monitoring systems, so it is a great choice for open-source libraries where you don't know beforehand which monitoring system will be used in the application.

Where is the information exported to?

The information can be exported to any compatible backend monitoring system that the library user chooses like Prometheus, Jaeger, AWS X-Ray or DataDog. The user of the library just needs to configure the appropriate exporter for their chosen backend. In the README example I've used the simplest ConsoleExporter which only makes sense to use for testing & demo purposes.

How often is it exported

The export frequency depends on the settings chosen by the user. They can configure the frequency to best suit their monitoring needs. The application is instrumented either manually or automatically using open source opentelemetry API. Exporters implement well defined API so they can be switched pretty easily.

What does it look like when exported? Do you have any screen shots or anything?

The exported data's appearance is determined by the monitoring system in use. OpenTelemetry exports metrics either in an open source export format defined by opentelementry specification or via extensions that support vendor specific formats. It doesn't make sense to include screenshots I guess because it depends on the target monironing system.

If you consider a task of adding metrics to the pgpubsub library with a requirement to support different monitoring systems you will either end up with a solution that would implement some kind of extension/plugin system like https://en.wikipedia.org/wiki/Service_provider_interface. Or you can use open source specification and API to export telemetry data like opentelemetry.

[PaulGilmartin]

I still plan to review this and likely merge it, I just haven't had time yet. I will prioritise for the next release.