Reduce CPU cycles spent on setting tracing tags

[RohanNagar]

Make sure that:

• You have read the contribution guidelines.
• You have created a feature request first to discuss your contribution intent. Please reference the feature request ticket number in the pull request.
• You applied code formatting rules using the mvn formatter:format target. Don’t submit any formatting related changes.
• You submit test cases (unit or integration tests) that back your changes.

Addresses #3308 to avoid creating a RedisURI object when setting tracing tags. As explained in the issue, the current behavior results in unnecessary CPU usage.

This change caches the necessary information that is added to span tags each time the channel is registered.

This should work as long as the RedisUri attribute attached to the channel doesn't change (is that a correct assumption?).

The alternative is to just extract the information each time from channel.attr(ConnectionBuilder.REDIS_URI).get(). Something like:

        if (channel.hasAttr(ConnectionBuilder.REDIS_URI)) {
            String redisUriStr = channel.attr(ConnectionBuilder.REDIS_URI).get();
            span.tag("server.address", redisUriStr);
            span.tag("db.namespace", extractedDbValueFromRedisUriStr);
            span.tag("user.name", extractedUsernameValueFromRedisUriStr);
        }

Closes #3308

[RohanNagar]

Hi @tishun I want to get your thoughts on this change - is it the right direction in order to address issue #3308? Thanks!

[tishun]

Hey folks, ignore this last submit, I have another idea

[RohanNagar]

Looking forward to a fix here!

[tishun]

Spent an unusually long time thinking about this and made a full circle on the solution.

Tracing back our conversation with @ggivo to give some context to everyone reading:

• in Propagate database number, user, and RedisURI into Tracing #3005 a solution was provided that aimed at resolving Propagate database number, user, and RedisURI into Tracing #2232, at the time I personally was not sure what was expected and it seemed like a reasonable fix
• However I now see that what Mark wanted was an extension of the Tracing facade, that abstracts away tracing for both the Brave and Micrometer tracers, and not a custom solution just for Micrometer (the confusing part was that he supplied a link to the Open Telemetry semantic conventions which is inherently tied with the Micrometer tracer)
• Now that we know the solution in Propagate database number, user, and RedisURI into Tracing #3005 only works for Micrometer I wanted to make it work for Brave too, but this goes beyond this fix.

Current solution:

• revert Propagate database number, user, and RedisURI into Tracing #3005 (fixes the tracing slowdown)
• reopen Propagate database number, user, and RedisURI into Tracing #2232
• revisit with a complete solution when we have time