Since multiplexed sessions can run more than one transaction concurrently, it shouldn't store a single span object. A new span object is created and stored in the context of the public method which is invoked. There are two changes in this PR

• setSpan() method is removed from the SessionTransaction interface in SessionImpl class.
• Modify setActive() method within SessionImpl interface.

setActive() method within SessionImpl does the below things

1. Handles nested transaction use-case
2. Invalidates active transactions - Disabling this will allow multiple transactions per session.
3. Resets readyTransactionId - The value for readyTransactionId is only set in the prepareReadWriteTransaction method. Otherwise the value anyway remains null.
4. Sets the span per active transaction - A session no longer can maintain a single span. Hence, we will require to change the way spans are added for multiplexed session. This is doable since for each new RPC, a new span object is created and stored in the local thread context. Instead of storing the span state in SessionImpl, we can fetch the span from context and set it.

For multiplexed session we are disabling #2, #3 and #4 for launching read-only transactions. The functionality of spans/traces for multiplexed session will be tested and added in a separate PR.

[surbhigarg92]

This might be an issue.

Closing in favor of - #3027