Add "instruments-any" feature: unblock multi-target instrumentations while fixing dependency conflict breakage.

[jeremydvoss]

Description

Fixes breaking change to autoinstrumentation dependency conflicts while supporting instrumentations that target multiple package, such as fastapi, psycopg2, and kafka-python. This is a partial revert of #3202 . It restores previous functionality of checking for dependency conflicts before loading instrumentors. However, it also provides a cleaner solution solving the problem at it's source. There is now a new instruments-any field in for instrumentor package.tomls. Unlike the instruments field which lists requirements all of which need to be present for the instrumentation, instruments-any provides requirements any of which need to be present. For instance, the following structure would indicate that the kafka-python instrumentation targets either kafka-python or kafka-python-ng:

[project.optional-dependencies]
instruments-any = [
  "kafka-python >= 2.0, < 3.0",
  "kafka-python-ng >= 2.0, < 3.0"
]

(The current status of the kafka-python instrumentation is that the toml only mentions kafka-python, but support for kafka-python-ng is added through the instrumentor object itself.)
For more complicated scenarios, see this example:

[project.optional-dependencies]
instruments = [
  "util ~= 1.0"
  "common ~2.0"
]
instruments-any = [
  "foo ~= 3.0"
  "bar ~= 4.0"
]

This would indicate that the instrumentation should only be loaded when you have the dependencies (util and common and (foo or bar))
In my next PR, I intend to add this feature to the kafka, fastapi, and psycopg2 tomls. This PR however, is focused on fixing the issue of autoinstrumentation loading instrumentations before dependency conflicts.

Fixes #3434

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• [?] Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Could be a breaking change if users took a dependency on the breaking change that this fixes. For this reason, I would like sign off from kafka and fastapi stakeholders especially
• This change requires a documentation update

How Has This Been Tested?

Added new unit tests, restored those deleted in #3202 and retrofitted those added.

Does This PR Require a Core Repo Change?

• Yes. - Link to PR:
• No.

Checklist:

See contributing.md for styleguide, changelog guidelines, and more.

• Followed the style guidelines of this project
• Changelogs have been updated
• Unit tests have been added
• Documentation has been updated

[jeremydvoss]

This PR's goal is to tackle a longstanding issue from the ground up. I want to make certain that all past stakeholders for the instrumentations I seek to help understand and are okay with it
kafka-python: @rjduffner
fastapi: @musicinmybrain @smoke @gryevns
psycopg2: @joshowen @emdneto @xrmx

[smoke]

I am not subject matter expert, but the idea perfectly makes sense to me and I like it.

[musicinmybrain]

Thanks for mentioning me on this. While I still maintain python-fastapi in Fedora, I orphaned python-opentelemetry-contrib and my other opentelementry-related packages some time ago, after I no longer needed them in connection with grpc. Therefore, I no longer have a stake in these instrumentations.

[gryevns]

Seems like a sensible approach and I believe this would have resolved the fastapi-slim package issue.

(minor) Maybe instruments_any over instruments_either.

[jeremydvoss]

instruments_any

@gryevns good idea, I'll consider switching the naming convection

[rjduffner]

Just starting reading here, but by partially reverting #3202, and not including #3612, doesn't this re-break kafka-python in the auto instrumentation case?

Specifically because kafka-python doesn't have the instruments either functionality yet and only has the instruments functionality which would mean, kafka-python and kafka-python-ng which doesn't ever happen.

[jeremydvoss]

Just starting reading here, but by partially reverting #3202, and not including #3612, doesn't this re-break kafka-python in the auto instrumentation case?

Specifically because kafka-python doesn't have the instruments either functionality yet and only has the instruments functionality which would mean, kafka-python and kafka-python-ng which doesn't ever happen.

Yes, we would want to change the kafka toml accordingly.