Fix/hikaricp metric split

[wuwen5]

• If this pull request closes/resolves/fixes an existing issue, replace the issue number. Closes #.
• Update the CHANGES log.

This PR separates HikariCP datasource metrics by category to avoid mixing connection-count metrics with time-based configuration metrics in the same metric family.

Previously, these metrics had different units and scales, which could distort line-chart visualization and make connection-related trends difficult to interpret. Separating the metrics ensures consistent units and improves the accuracy and readability of datasource metric visualization.

old

new

[wu-sheng]

Could you be clear how the old metrics look like? and how about your new proposals?

[wu-sheng]

Thanks for the PR. The mixed-unit chart is a real problem, but I don't think a new metric is the right fix.

1. OAP's only MAL rule for this is meter-analyzer-config/datasource.yaml, and it reads just datasource (datasource.sum(['service', 'instance', 'name', 'status'])). Nothing consumes datasource_time, so the agent would keep collecting these four values and OAP would silently drop them. They'd never be stored or queryable.
2. connectionTimeout, validationTimeout, idleTimeout and leakDetectionThreshold are pool configuration, not runtime metrics. They're flat lines. HikariCP's own Micrometer tracker doesn't export them either.

So I'd suggest we stop collecting them instead of adding a new metric:

• Remove the four timeout gauges from PoolingSealInterceptor. Keep minimumIdle and maximumPoolSize in datasource: they're counted in connections, and they serve as limit lines for the active/total connection counts.
• Remove the four entries from hikaricp-scenario/config/expectedData.yaml, rather than renaming them.
• Update the CHANGES.md line to say these config values are no longer reported.

No OAP MAL or UI changes are needed. The datasource rule sums over every status value, so it keeps working unchanged. The UI's datasource chart will then show only connection counts, which fixes the chart you showed.

For consistency, please do the same for dbcp's maxWaitMillis and c3p0's maxIdleTime, which are the same kind of time-based config in the same metric family. That means updating dbcp-2.x-scenario and both c3p0 scenarios. Either this PR or a follow-up works.

The runtime signals about connection timeouts are already covered:

• threadsAwaitingConnection greater than 0 shows the pool is running out of connections.
• An actual getConnection() timeout marks the HikariCP/Connection/getConnection span as an error, with the exception attached.