Modify toSpanData to happen inside attributesLock to prevent data races

[ArielDemarco]

Overview

This PR addresses a potential data race issue when toSpanData() is called concurrently with modifications to attributes by wrapping both operations within the same lock.

Explanation

When somebody needs to call toSpanData during the lifetime of a Span, the toSpanData() method accesses attributes and totalAttributeCount while another thread may be modifying them (each time an attribute is added/removed totalAttributeCount is also modified), leading to potential crashes or memory corruption.

Fixes #630

[nachoBonafonte]

Sorry I just realized that it must be locked also with the other lock (the event one) as also events could be modified in while calling it ( this pattern is also used in the stop method)

[ArielDemarco]

Sorry I just realized that it must be locked also with the other lock (the event one) as also events could be modified in while calling it ( this pattern is also used in the stop method)

You're right! that lock also wraps properties that are going to be used by the toSpanData method so it should be wrapped by that lock too. Already made the commit

[ArielDemarco]

Seems like adding the eventsSyncLock causes a deadlock (that's why tests are failing), cause inside of the withLock in toSpanData there's a call to adaptEvents() which also uses the eventsSyncLock. Seems that every other thing locked with the eventsSyncLock is also being called directly from the toSpanData (adaptEvents, getTotalRecordedEvents).
So maybe is safe to say that the best thing to do is to remove the eventsSyncLock usage in this method? what do you think @nachoBonafonte ?

[nachoBonafonte]

Yes, if all the calls being made by the method are covered then it is not needed. It was my fault asking you to add it, I should have checked first, sorry.

[ArielDemarco]

No problem! did the rollback! Hope next run works fine

[nachoBonafonte]

It worked with last changes so I merged. Thanks a lot.