[Exporters] Add bytes egressed metrics for exporters

[splunkericl]

Is your feature request related to a problem? Please describe.
Currently, the observability data for exporters only include number of events sent successfully/failed. Our application is interested in the exact bytes transmitted by the exporters.

This raw bytes should be however much the exporter sends over the network. e.g: compressed bytes sent over HTTP.

Describe the solution you'd like
Creating a new extension that each exporter can optionally use for egress observability data.
The interface of the data would be:

type ExporterObservabilityExtension interface {
   // OnExport is called when the exporter successfully export a record
   // the bytes represents the bytes transmitted and the dimensions are the
   // key-value pairs for the metrics.
   OnExport(bytes int64, dimensions map[string]string)

   // OnHeartbeat is called when an exporter heartbeats its destination.
   // if err is nil, the heartbeat was considered successful. Otherwise, it
   // is considered a failure.
   OnHeartbeat(err error, dimensions map[string]string)
}

The exporter EP plans to incorporate will have the option to initialize these extensions. Example changes to SplunkHecExporter

// SplunkHecExporter Config
type Config struct {
   …
   // Initialize if provided and provide observability if initialized
   ObservabilityExtId *string
}

Pros:

• Different users require different extensions can customize to their needs
• Different users of SplunkHecExporter can choose to enable it
  Cons:
• Need to be manually added in each exporter

Describe alternatives you've considered
Similar to obsreport for the receiver, there is a obsreport for the exporter. This module is used inside exporter helper when records are sent from the exporter helper.

Currently, the number of events sent successfully/unsuccessful are reported by obsreport. To address EP’s use case, the new parameter can be added to report the number of bytes.

New exporting heartbeat helper method can be added so each exporter can implement them.

Pros:

• Can automatically apply to all exporters
  Cons:
• Only counts event size
• Affects every exporter even if the users don’t care about byte metrics

Additional Context
receivers equivalent github issue: #7308

[bogdandrutu]

What is the point of having an extension vs having a otel metric directly?

[splunkericl]

I was thinking using an extension is more future proof. The users can implement the interface for the client on how to want to observe the data. They can use a different observability framework or observe using their namespace, dimensions, etc.

But if we want to keep it simple to start we can just have otel metric directly. If there are more use cases in the future create the extension by them.

[jmacd]

Strong support for this and #7308. Here is my previous attempt #6712

[jmacd]

In the discussion around #6712, @bogdandrutu asked whether we should wait for a standard OTel-Go-Contrib gRPC or HTTP instrumentation to do this (e.g., open-telemetry/opentelemetry-go-contrib#3002). I am wary of blocking this work on that work.

[splunkericl]

I am definitely interested in the changes in #6712. We would be interested in the http handler part and can introduce that.

@bogdandrutu what is the plan for standard Otel-Go-Contrib instrumentation so far? The PR like open-telemetry/opentelemetry-go-contrib#3002 is 4 months old and don't see much tractions there.