Revert "Add InstrumentationLibrary to Sampler.ShouldSample (#1850)"

[iNikem]

This reverts commit f936f2e.

During today Maintainers meeting @jmacd expressed his concern about #1658 and the direction that it moves SDK: runtime decisions in Samplers as opposed to configuration-time decisions of configuring SDK and/or Tracers with the correct Samplers. His opinion was that we should use the latter: all decisions based on Resources and InstrumentationLibraries can be done before providing Tracers to the users. Thus those Tracers can already use Samplers chosen/narrowed down based on that information. Thus they don't need to accept it in ShouldSample method.

Several attendees, myself including, agreed that this is a reasonable idea. It was thus decided to revert introducing InstrumentationLibrary to ShouldSample method and get back to the drawing board to choose between two approaches:
either pass both Resources and InstrumentationLibrary to ShouldSample in one spec release OR don't pass neither of them and allow SDKs to configure specific Sampler for a specific Tracer.

[Oberon00]

As discussed during today Maintainers meeting.

Please provide a more detailed justification for those that did not attend (feel free to dismiss my review after that)

[yurishkuro]

Please provide a more detailed justification for those that did not attend (feel free to dismiss my review after that)

+1. Do we need to improve our community guidelines to make it clear that "was discussed in a meeting" is never a justification for any change?

[iNikem]

Sorry, updated PR's description

Concern addressed

[Oberon00]

Please ensure a follow-up issue for this new configuration design is created before merging.

[jsuereth]

@Oberon00 I'm not sure what you mean here. Can you clarify? I'd like to understand what you'd like to see before moving this PR forward.

[Oberon00]

Quoting the description:

get back to the drawing board to choose between two approaches:
either pass both Resources and InstrumentationLibrary to ShouldSample in one spec release OR don't pass neither of them and allow SDKs to configure specific Sampler for a specific Tracer.

There should be an issue for that. Probably it will be best to use the existing #1588, copying & pasting the gist to that issuewould make sense. And of course, adding a "Closes #1588" to the description to close the PR for adding resources, which then wouldn't make sense at all.

[iNikem]

Added #1588 (comment)

[carlosalberto]

@Oberon00 Wanted to double confirm you are fine with Nikita's comment, and we can merge this one?

[Oberon00]

I need to correct my previous comment: I meant to suggest "Closes #1658", #1588 is obviously not resolved.

But yes, I'm OK with merging this PR, although with a somewhat uneasy feeling, as I fear this will keep #1588 in the backlog for quite some time.