Add thread safety to SimpleSpanProcessor

[jsuereth]

Changes:

• Ensure calls to the configured Exporter are locked behind an atomic_flag.
• We use a spin-lock for now, under the assumption that Exporter calls are fast.

Notes:

1. I tried really really hard to write a test that would fail if the locking wasn't in place, and was unable to make anything consistent/worthwhile, so that's dropped. If you have a good idea to how to write a test to ensure locking is done properly and failure to lock causes an issue, more than happy to add it.
2. I thought spin-lock usage was "ok" given two assumptions: (a) Exporter calls will be 'fast' and (b) "simple" processor is not likely to be used over the buffering processor. If either of these are wrong, please let me know.
3. The spin-lock itself could easily be improved w/ C++20x mechanisms or by pulling in some helpful utilities to better do exponential-back-off and provide better processor instructions instead of just looping. I think that this code would also benefit the *Provider classes that do similar spin-locking.

[linux-foundation-easycla]

The committers are authorized under a signed CLA.

• ✅ Josh Suereth (14814a3, 6aa6b29)

[jsuereth]

@pyohannes let me know if this is in line with what you were thinking!

[codecov]

Codecov Report

Merging #358 into master will decrease coverage by 0.04%.
The diff coverage is 88.88%.

@@            Coverage Diff             @@
##           master     #358      +/-   ##
==========================================
- Coverage   94.95%   94.90%   -0.05%     
==========================================
  Files         154      155       +1     
  Lines        6854     6874      +20     
==========================================
+ Hits         6508     6524      +16     
- Misses        346      350       +4     

Impacted Files	Coverage Δ
sdk/include/opentelemetry/sdk/trace/exporter.h	100.00% <ø> (ø)
sdk/include/opentelemetry/sdk/trace/processor.h	100.00% <ø> (ø)
sdk/test/trace/simple_processor_test.cc	86.20% <78.94%> (-13.80%)	⬇️
api/include/opentelemetry/common/spin_lock_mutex.h	100.00% <100.00%> (ø)
api/include/opentelemetry/metrics/provider.h	100.00% <100.00%> (ø)
api/include/opentelemetry/trace/provider.h	100.00% <100.00%> (ø)
...include/opentelemetry/sdk/trace/simple_processor.h	87.50% <100.00%> (+1.78%)	⬆️

[pyohannes]

Looks good, and improves the quality of our code base. Thanks!

I only have one nit, but this is ready to merge.

[reyang]

LGTM.

[lalitb]

Nit: We can also add a try_lock() method (as provided by std::mutex ) which returns immediately with status. It will provide flexibility to caller whether try acquiring in tight loop, or lazy way . This mayn't be usable through lock_guard, but still useful if caller is not concerned about RAII. Something like:
bool try_lock() { return !flag_.test_and_set(std::memory_order_acquire)) }