* Fix event type of export data is incorrect, it was `EventType.TOTAL` always.
* Reduce redundancy ThreadLocal in MAL core. Improve MAL performance.
* ExpressionDelegate public->private
* [**Breaking Change**] Remove **Deprecated responseCode** from sources, including Service, ServiceInstance, Endpoint
* Enhance endpoint dependency analysis to support cross threads cases. Refactor span analysis code structures.
* Remove `isNotNormal` service requirement when use alias to merge service topology from client side. All RPCs' peer
services from client side are always normal services. This cause the topology is not merged correctly.
-----------
In our showcase and Java agent scenarios, there are several cross-thread tracing cases, we were not generating endpoint dependency if ref exists in local and exit span. In this PR, I am adding this missing part back.
Also, in case the downstream endpoint of the dependency is another local/exit span's operation name, which was not generating endpoint traffic before, I add traffic generation of both sides' endpoints of dependency.
Another important point that drives me to fix this is, in the new Booster UI, metrics of endpoint dependency are shown in a separate dashboard, which requires the endpoints of both sides existing in metadata, otherwise, nothing shows up.
For e2e, updated the Java agent to the latest.
Previous logic can't update the mappings `properties parameters` and `_source` only support adding a new property.
### Now
1. As the OAP core merges the index of metrics, properties would not be deleted still.
2. Would not update the current index to avoid conflict, a new index follows the new template to create.
**Warning**, if there are properties conflicts, same key with different values, they would override each other according to booting sequence. Unless we change booting process as merging modules before merging with existing templates and indices, we can't add check mechanism and warnings.
* Add `Column.shardingKeyIdx` for column definition for BanyanDB.
```
Sharding key is used to group time series data per metric of one entity in one place (same sharding or same
column for column-oriented database).
For example,
ServiceA's traffic gauge, service call per minute, includes following timestamp values, then it should be sharded by service ID
[ServiceA(encoded ID): 01-28 18:30 values-1, 01-28 18:31 values-2, 01-28 18:32 values-3, 01-28 18:32 values-4]
BanyanDB is the 1st storage implementation supporting this. It would make continuous time series metrics stored closely and compressed better.
NOTICE, this sharding concept is NOT just for splitting data into different database instances or physical files.
```
* Add `JD_PRESERVE_LINE_FEEDS=true` in official code style file. Then our comments don't have to use many blank lines to keep format.
* Add storage column attribute `indexOnly`, support ElasticSearch only index and not store some fields.
* Add `indexOnly=true` to `SegmentRecord.tags`, to reduce unnecessary storage.
* Enhance DataCarrier#MultipleChannelsConsumer to add priority for the channels, which makes OAP server has a better
performance to activate all analyzers on default.
* Activate `receiver-otel#enabledOcRules` receiver with `k8s-cluster,k8s-node,k8s-service,oap,vm` rules on default.
* Activate `satellite,spring-sleuth` for `agent-analyzer#meterAnalyzerActiveFiles` on default.
* Activate `receiver-zabbix` receiver with `agent` rule on default.