* Fix datasource-proxy log-level is not working
- Aligned default values of `Query` & `SlowQuery` in
`TraceJdbcProperties.DataSourceProxyProperties`
and `DataSourceProxyProperties`
- Add code to copy properties of `Query` and `SlowQuery` in
`DataSourceProxyConfiguration`
- Add test case to check if `log-level` can be override or not.
Fixes gh-1973
* Disable query log listener by default
- By default `QueryLogListener` and `LoggingQueryLogListener`
will be disabled, dev need to enable it by using properties
- By default `Slf4j` will be enlabled for query logging
so by adding below property slow query logging will be enabled
`spring.sleuth.jdbc.datasource-proxy.slow-query.enable-logging=true`
this property will register `SLF4JSlowQueryListener`
* Add docs for how-to enable data-proxy query logs
* simplify ON_EACH reactor instrumentation
remove custom Publisher decorators that
were mostly copy of reactor-core Lift Publishers
and use new LIFTER Scannable Attribute instead
* change constant scope
* add note about test constant origin
without this change there were cases (that we didn't test) where the tracing context would leak and pollute other parts of the code (including tests)
with this change we ensure that in case of errors we don't allow any dangling tracing context
* TracingChannelInterceptor: simple refactoring
* * More clean up in the `TracingChannelInterceptor`
- Move Spring Cloud Stream classes logic into `static` methods
to avoid eager load for those classes which are not present on CP
- Remove `emptyMessage()` since the contract for `ChannelInterceptor`
never accept a `null`
- Remove thread state manipulation from the `postReceive()` since
no one takes care about thread local afterwards
- Remove `afterReceiveCompletion()` in favor of its `default` impl
in the interface: we don't do thread local manipulation for `receive()`
since `afterReceiveCompletion()` is called *before* the message is really
returned to the target subscriber on the channel
* * Restore span manipulation for `receive()`.
Even if we don't need a thread local store, we still
need to call `span.end()` and set an exception tag
to it if any.
So, just reuse an existing API which includes thread local.
Even if we don't need it logically, there might be some
other interceptors in between which would like to take a
span from thread local do something even on that "void"
`receive()` operation
Without this change we don't even really know how many tags are created and what are their values.
With this change we want this information to be automatically rendered.
