feat(RelayOpenTelemetry): add db.statement attribute

[vmihailenco]

There probably should be a way to disable this attribute in case the value is too large, but I am not sure how the API should look like so I left it for a future PR.

[vmihailenco]

PTAL. I've added db.statement attribute for *scan operation and transactions.

[tillkruss]

This won't work with __construct() and connect() and some other, which aren't Redis commands, but Relay specific methods.

[vmihailenco]

"This" is db.statement? Why it does work for db.operation?

[tillkruss]

That's also sending invalid data currently. We're working on the stubs to make this easier.

[tillkruss]

This will make it easier to identify various types of methods: https://relay.so/api

[vmihailenco]

Okay, sounds like I should wait for some input from you.

[tillkruss]

@vmihailenco: We're exploring whether we can use 8.0 attributes in the class stubs. If so we could use reflection to check whether a method should be bypassed (setOption()), should be traced (connect()) or whether it's a Redis command (mget()).

Instead of maintaining arrays of functions we could parse all class methods once, or each method once when it's executed.

[vmihailenco]

Thanks for update. Let me know what changes do you expect here.

My 5 cents are that I would not worry about this. I'd say that tracing connect is the right thing to do and having setOption also would not hurt. Are you worried about having db.statement on such spans? Again, I don't see what real issues that causes.,,

[tillkruss]

Closing in favor of 21f4e06.