GH-6372: Expose client request metrics.

[chickenchickenlove]

Motivation:

Because of #6372 .

Modifications:

• Add new class ClientMetrics.
• HttpClientFactory has ClientMetrics as its field.
• HttpChannelPool has ClientMetrics as its field.
• HttpChannelPool calls ClientMetrics whenever calling setPendingAcquisition(...) and removePendingAcquisition(...).
• HttpSessionHandler calls ClientMetrics to increment count for active request and reserve to decrement count of active request.

Result:

• Closes Expose client request metrics #6372

[github-actions]

🔍 Build Scan® (commit: 54dc0e3)

Job name	Status	Build Scan®
build-ubicloud-standard-16-jdk-8	✅	https://ge.armeria.dev/s/cqbbmxeot7s5y
build-ubicloud-standard-16-jdk-21-snapshot-blockhound	✅	https://ge.armeria.dev/s/kbzxjmlo4czya
build-ubicloud-standard-16-jdk-17-min-java-17-coverage	❌ (failure)	https://ge.armeria.dev/s/doaec5xftxwh6
build-ubicloud-standard-16-jdk-17-min-java-11	✅	https://ge.armeria.dev/s/h4vvxedjc7nyq
build-ubicloud-standard-16-jdk-17-leak	✅	https://ge.armeria.dev/s/4mwplnkwtyalc
build-ubicloud-standard-16-jdk-11	✅	https://ge.armeria.dev/s/kpgcb5cidhp3g
build-macos-latest-jdk-21	✅	https://ge.armeria.dev/s/mlexljscamzcc

[jrhee17]

Question) If the objective is to determine the optimal number of event loops depending on pending requests for each endpoint group/protocol, would it be enough to check the duration instead?

final EndpointGroup endpointGroup = ctx.endpointGroup();
ctx.log().whenComplete().thenAccept(log -> {
    final long pendingDuration = log.connectionTimings().pendingAcquisitionDurationNanos();
    final SessionProtocol sessionProtocol = log.sessionProtocol();
});