Remove default parameters from Recordable interface

[nadiaciobanu]

This previous PR added support for links and event attributes in the base Recordable. Some parameters of the virtual functions were assigned defaults (for example the default timestamp is now and default attributes are an empty map). This was done to conform to the OpenTelemetry spec (see Add Events and Add Links).

After further research, I found that many people strongly recommend against using default parameters in virtual functions, since default parameters depend on the static type of the object, whereas the virtual function dispatched depends on the dynamic type (see a discussion here). In fact, the Google C++ Style Guide goes as far as to ban default parameters on virtual functions.

This PR replaces the default parameters in the Recordable virtual functions with function overriding. I believe this will lead to more consistent and predictable behaviour. It will also remove the need for each derived class of the base Recordable to re-define the default parameters.

I've also added a static empty map to the base Recordable, to avoid creating a new empty map every time the default attributes are used.

[codecov]

Codecov Report

Merging #208 into master will increase coverage by 0.01%.
The diff coverage is 87.50%.

@@            Coverage Diff             @@
##           master     #208      +/-   ##
==========================================
+ Coverage   92.30%   92.31%   +0.01%     
==========================================
  Files         101      102       +1     
  Lines        3169     3174       +5     
==========================================
+ Hits         2925     2930       +5     
  Misses        244      244              

Impacted Files	Coverage Δ
sdk/include/opentelemetry/sdk/trace/span_data.h	98.33% <50.00%> (ø)
...nclude/opentelemetry/sdk/common/empty_attributes.h	100.00% <100.00%> (ø)
sdk/include/opentelemetry/sdk/trace/recordable.h	100.00% <100.00%> (ø)
sdk/test/trace/span_data_test.cc	100.00% <100.00%> (ø)

[reyang]

LGTM.

[nadiaciobanu]

@pyohannes @IlyaKobelevskiy please let me know if you have any further thoughts!

[pyohannes]

This looks good. The current flaky PR builder shouldn't block a merge. @reyang