feat: add ParentOrElseSampler

[legendecas]

Which problem is this PR solving?

• Fixes Replace ALWAYS_PARENT sampler with ParentOrElse sampler #1075

Short description of the changes

• Added ParentOrElseSampler.
• Renamed ALWAYS_SAMPLER and NEVER_SAMPLER to AlwaysOnSampler and
  AlwaysOffSampler respectively.

[codecov]

Codecov Report

Merging #1279 into master will increase coverage by 0.03%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #1279      +/-   ##
==========================================
+ Coverage   93.12%   93.16%   +0.03%     
==========================================
  Files         133      136       +3     
  Lines        3841     3862      +21     
  Branches      785      788       +3     
==========================================
+ Hits         3577     3598      +21     
  Misses        264      264              

Impacted Files	Coverage Δ
...lemetry-core/src/trace/sampler/AlwaysOffSampler.ts	100.00% <100.00%> (ø)
...elemetry-core/src/trace/sampler/AlwaysOnSampler.ts	100.00% <100.00%> (ø)
...etry-core/src/trace/sampler/ParentOrElseSampler.ts	100.00% <100.00%> (ø)
...metry-core/src/trace/sampler/ProbabilitySampler.ts	82.35% <100.00%> (-1.86%)	⬇️
packages/opentelemetry-tracing/src/config.ts	100.00% <100.00%> (ø)

[obecny]

lgtm,
with regards to description I would prefer having separate unit tests for that only so it is easier to spot the spec requirement for it whenever something fails.

[legendecas]

@obecny The sampler's description is depends on the parameters they were constructed, e.g. for ProbabilitySamplers their description can be ProbabilitySampler{1.0} or ProbabilitySampler{0.5}, and for ParentOrElseSamplers their description can be ParentOrElseSampler{ProbabilitySampler{1.0}} or ParentOrElseSampler{AlwaysOffSampler}. So separating their description assertion from their parameterized tests may cause verbosity.

[obecny]

@obecny The sampler's description is depends on the parameters they were constructed, e.g. for ProbabilitySamplers their description can be ProbabilitySampler{1.0} or ProbabilitySampler{0.5}, and for ParentOrElseSamplers their description can be ParentOrElseSampler{ProbabilitySampler{1.0}} or ParentOrElseSampler{AlwaysOffSampler}. So separating their description assertion from their parameterized tests may cause verbosity.

It really doesn't matter. The unit tests are meant to test one thing so if some test fails you know exactly what happens. Knowing that if you create a unit test

it('should have correct description', ()=> {
....
}) 

whenever it fails you know exactly that there is a problem with description and you know where to look.

But you created a unit test

it('should return api.SamplingDecision.RECORD_AND_SAMPLED for AlwaysOnSampler'

so if it fails you have no idea why it failed whether it was sampling decision or something different in this case the description.
Also checking something more in certain unit test when the title says 'should return api.SamplingDecision.RECORD_AND_SAMPLED for AlwaysOnSampler is imho wrong, you should simply create a new unit test for that with a proper title.

[obecny]

should return api.SamplingDecision.NOT_RECORD for not sampled parent while composited with AlwaysOnSampler
imho it should looks like this

describe('when parent is not sampled', ()=> {
  describe('AND composited with AlwaysOnSampler',()=>{
    it('should return api.SamplingDecision.NOT_RECORD', ()=> {
    });
    it('should have correct description', ()=> {
    });
  })
  describe('AND composited with ...',()=>{
.....
})

etc.

[legendecas]

@obecny 👋 , tests updated, PTAL :)