Middleware: extension interface (part 1/4)

[jmacd]

Description

Adds the extension API from #12842.

Link to tracking issue

Part of #12603.

Testing

Not tested. See configmiddleware.

Documentation

Added.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 91.46%. Comparing base (6342522) to head (4ee26cc).
Report is 4 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main   #12843   +/-   ##
=======================================
  Coverage   91.46%   91.46%           
=======================================
  Files         493      493           
  Lines       26984    26984           
=======================================
  Hits        24682    24682           
  Misses       1818     1818           
  Partials      484      484           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[bogdandrutu]

For the spell checker we need to allow the configmiddleware word.

[bogdandrutu]

Also please fix the checks:

verifyAllModulesInSet failed: Module go.opentelemetry.io/collector/extension/extensionmiddleware (defined in /home/runner/work/opentelemetry-collector/opentelemetry-collector/extension/extensionmiddleware/go.mod) is not listed in any module set.

[jade-guiton-dd]

I don't have much context on the middleware work, but lints aside, this looks good to me.

[jade-guiton-dd]

How certain are we that DialOptions/ServerOptions fulfill all the envisioned use cases for middlewares? (I don't know of any counter-examples but just want to confirm)

I'm also wondering if some extensions might require context on what receiver/exporter they're being applied to, or what configgrpc.Config is being applied

[jmacd]

This is a fair question. I've answered it partly in the README, see 4056d60.

This is one of two chances to identify which component is connecting a middleware extension--if the confighttp or configgrpc struct that contains the middleware reference would pass in this information, we could use it, but we don't have that information presently. To be clear, confighttp and configgrpc and configauth also do not know which component they are acting for. We could use the Context passed to component Start() to identify the component that is starting, as a workaround. Should we add Context arguments to these functions? Should we consider modifying confighttp and configgrpc now to include the calling component explicitly?

Note that we don't know which signal is responsible for the activation, which is at least equally relevant. In the context of middleware, you can typically inspect a path or method name to learn which signal is involved. For the limiter extension that I prototyped as part of #12700, the same would not apply, and we will have to decide whether to be explicit (e.g., via a Settings argument) or implicit if we want to pass this information to the extension at Start() or at runtime.

[jmacd]

For the spell checker we need to allow the configmiddleware word.

Can we talk about how the top-level Makefile runs a different spelling program than the Github action?

Also please fix the checks:

😭 My personal hell is having people point out robot feedback, especially in a repo where the top-level Makefile provides no useful help. ;)