Performance: poor performance solution for rate measurement PcesReplayer.replayPces()

### Description

By Tom's experiment engnet2-20240906_175600 (see details below),
it was performance-triaged that the following rate measurement logic could be more optimized:

[](https://perf.analytics.eng.hashgraph.io/permanent/engnet2-20240906_175600/reports/com.swirlds.platform.event.preconsensus.PcesReplayer.html#176)
https://perf.analytics.eng.hashgraph.io/permanent/engnet2-20240906_175600/reports/com.swirlds.platform.event.preconsensus.PcesReplayer.html#176


Experiment details:
```
The mix2k should contain the entire idle period plus the load period includes at least the first 15 mins of the peak level
clients started to complain PLATFORM_TRANSACTION_NOT_CREATED like errors basically above 500 TPS level thus we lost about 1/5 to 1/4 of intended traffic(aiming for 2k total). But all smartcontract tx went through as it was able to reach the 15M gas usage and had been able to stay just below it. But looks like 2K is the limit for us given the elevated secC2C
```
Grafana: [](https://preproduction.grafana.hedera-ops.com/d/ec9413c6-6f17-49fc-951b-51cbc21a1eef/network-health?var-network=engnet2&var-NodeID=$__all&from=2024-09-06T18:50:38.903Z&to=2024-09-06T20:03:20.891Z)

### Steps to reproduce

It will be easy to reproduce as perf/algorithm analysis will in GHA (to do:on me). Performance code-review is capable to deduce the logic by annotated sources..

### Additional context

_No response_

### Hedera network

_No response_

### Version

v0.53

### Operating system

Linux

Start with PcesReplayer.replayPces() and the linked performance report, then inspect the annotated rate-measurement logic described in the issue. Use the planned performance or algorithm analysis in GHA to compare the optimized behavior against the reported high-throughput scenario.

Written by the indexing model from the issue text.