feat(exporter-collector): implement concurrencyLimit option

[dobesv]

This adds an option to the collector exporters concurrencyLimit. If this is set and
the number of export operations is equal to the limit, additional export operations
will fail immediately.

This should be set in combination with the batch span processor be set such that the
concurrency limit would not be reached under "normal" circumstances - only if there
is an issue would spans start to be dropped.

This helps us cap the amount of memory & sockets used by the exporter if it is not
able to keep up with the data it is being provided.

This could happen if the local network (e.g. in a browser) or the remote collector
are too slow to handle all the activity.

If we do not have this cap, and the exporter cannot keep up, resources such as
memory and network sockets can be consumed without limit, causing crashes and
other undesirable outcomes far worse than losing some telemetry data.

This also updates the examples to use BatchSpanProcessor as I couldn't really
think of any reason why you would want to use SimpleSpanProcessor in combination
with the collector exporter.

Fixes #1707

[codecov]

Codecov Report

Merging #1708 (2eda370) into master (1a24f40) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master    #1708   +/-   ##
=======================================
  Coverage   91.91%   91.92%           
=======================================
  Files         167      167           
  Lines        5567     5573    +6     
  Branches     1183     1186    +3     
=======================================
+ Hits         5117     5123    +6     
  Misses        450      450           

Impacted Files	Coverage Δ
...ages/opentelemetry-exporter-collector/src/types.ts	100.00% <ø> (ø)
...ry-exporter-collector/src/CollectorExporterBase.ts	92.30% <100.00%> (+1.00%)	⬆️

[dobesv]

Note: I considered setting some non-infinite default value for concurrentLimit but left it as it is now to avoid changing the behavior of the library.

[dobesv]

I don't know why it thinks the changes are not covered by the unit tests, they seem to be covered to my eye.

[dyladan]

The implementation itself LGTM but @obecny wrote most of this code so I'm going to defer to him as to if this is a good idea we should merge or not.

[obecny]

@dobesv pls do not force push after 1st review is done, it is impossible to see changes then

[dobesv]

@obecny Thanks for the review. I have pushed changes that I hope addressed your comments. Let me know if there's anything more I can do to help.

[dobesv]

@obecny Ah sorry about the force push, it's a habit from other places that want a single commit.

[dyladan]

We squash it when we merge anyways. No need to worry about it during the PR process.

[obecny]

lgtm