unifying shutdown across code base

[obecny]

This PR is a follow up on graceful shutdown. What it does it is fixing and unifying the shutdown across all exporters, metric, spans, processors, so that the shutdown will be correctly handle in whole pipeline. It will also return promise that will resolve correctly when all tasks that depends on it will resolve including http or grpc request.

[codecov]

Codecov Report

Merging #1439 into master will decrease coverage by 0.29%.
The diff coverage is 80.81%.

@@            Coverage Diff             @@
##           master    #1439      +/-   ##
==========================================
- Coverage   94.11%   93.81%   -0.30%     
==========================================
  Files         153      153              
  Lines        4671     4756      +85     
  Branches      959      951       -8     
==========================================
+ Hits         4396     4462      +66     
- Misses        275      294      +19     

Impacted Files	Coverage Δ
...emetry-metrics/src/export/ConsoleMetricExporter.ts	58.82% <0.00%> (-3.68%)	⬇️
...s/opentelemetry-metrics/src/export/NoopExporter.ts	50.00% <0.00%> (-16.67%)	⬇️
packages/opentelemetry-metrics/src/export/types.ts	100.00% <ø> (ø)
...ges/opentelemetry-tracing/src/NoopSpanProcessor.ts	71.42% <50.00%> (ø)
...ckages/opentelemetry-exporter-jaeger/src/jaeger.ts	86.07% <72.00%> (-8.76%)	⬇️
...elemetry-tracing/src/export/SimpleSpanProcessor.ts	84.00% <75.00%> (-1.00%)	⬇️
packages/opentelemetry-metrics/src/Meter.ts	94.30% <76.92%> (-2.12%)	⬇️
...ry-exporter-collector/src/CollectorExporterBase.ts	92.00% <80.00%> (-2.74%)	⬇️
...telemetry-tracing/src/export/BatchSpanProcessor.ts	91.93% <80.76%> (-0.52%)	⬇️
...ackages/opentelemetry-metrics/src/MeterProvider.ts	90.47% <81.81%> (-6.08%)	⬇️
... and 8 more

[dyladan]

In general there are many functions which return promise and could benefit from using async/await. If the purpose of the PR is to unify the APIs, then we should move to the more modern solution.

[obecny]

In general there are many functions which return promise and could benefit from using async/await. If the purpose of the PR is to unify the APIs, then we should move to the more modern solution.

async is not supported on web and this will always be converted into fake generators so the number of code will be significant bigger then just a promise. Also you don't need to always use async - just because it is newer doesn't mean it can / should be used always, specially when you run the same async tasks in parallel instead of trying to wait for each task before running next one etc.

[dyladan]

In general there are many functions which return promise and could benefit from using async/await. If the purpose of the PR is to unify the APIs, then we should move to the more modern solution.

async is not supported on web and this will always be converted into fake generators so the number of code will be significant bigger then just a promise. Also you don't need to always use async - just because it is newer doesn't mean it can / should be used always, specially when you run the same async tasks in parallel instead of trying to wait for each task before running next one etc.

Ok that's fine. I didn't mean to imply that newer is always better, I just happen to find async/await style significantly more readable. The argument about generators I do understand and appreciate though.

[dyladan]

@open-telemetry/javascript-approvers Please take a look at this PR. It is a follow up from Jonah's "graceful shutdown" PR

[markwolff]

Looks great!