Replace WeakConcurrentMaps with SpanConcurrentHashMaps

[eyalkoren]

What is this about?

Switching to SpanConcurrentHashMap wherever applicable has two major benefits:

1. reference counting is enforced and maintained centrally, ensuring spans are not recycled ahead of time and still being referenced, therefore potentially used
2. in combination with our MockReporter recycling assertions, this enables us locating places where spans/transactions are not actively removed from WeakConcurrentMaps, thus relying on GC to clear them away. By reducing those to a minimum, we can dramatically decrease the number of WeakReferences that are "active" at any given moment, thus considerably reduce GC-related overhead.

Plugin Checklist

• gRPC - Replace WeakConcurrentMaps with SpanConcurrentHashMaps in gRPC plugin #2081
• AsyncHttpClient - Replace WeakConcurrentMaps with SpanConcurrentHashMaps in simple plugins #2093
• Dubbo - Replace WeakConcurrentMaps with SpanConcurrentHashMaps in simple plugins #2093
• Generic concurrent plugin - Switching to use SpanConcurrentMap in the concurrency plugin #2173
• Lettuce - Replace WeakConcurrentMaps with SpanConcurrentHashMaps in simple plugins #2093
• External process tracing - Replace WeakConcurrentMaps with SpanConcurrentHashMaps in simple plugins #2093
• HttpUrlConnection - Switching to SpanConcurrentHashMap in HttpUrlConnection instr #2300
• Vert.x 3 - Switch to using Span concurrent weak map in Vert.x 3 #2322
• Scala - Switching to use Span concurrent map in Scala plugin #2323

[SylvainJuge]

Added this to the next milestone so we can prioritize this migration.