'No sync target' logging improvements

[mark-terry]

Signed-off-by: mark-terry mark.terry@consensys.net

PR description

"No sync target, checking current peers for usefulness" logging made less spammy, with improved detail.

• DEBUG level log message rate reduced to once every 15 seconds, with pivot block target added to logging message.
• INFO level log message added at 2 minute intervals to provide user feedback while import is paused

Fixed Issue(s)

Addresses #4794

Documentation

• I thought about documentation and added the doc-change-required label to this PR if
  updates are required.

Changelog

• I thought about the changelog and included a changelog update if required.

[siladu]

I know log throttling is done in at least one other place:

besu/ethereum/api/src/main/java/org/hyperledger/besu/ethereum/api/jsonrpc/internal/methods/engine/EngineForkchoiceUpdated.java

Lines 287 to 296 in 7d5988d

	private void logForkchoiceUpdatedCall(
	final BiConsumer<EngineStatus, EngineForkchoiceUpdatedParameter> logAtLevel,
	final EngineStatus status,
	final EngineForkchoiceUpdatedParameter forkChoice) {
	// cheaply limit the noise of fcU during consensus client syncing to once a minute:
	if (lastFcuInfoLog + ENGINE_API_LOGGING_THRESHOLD < System.currentTimeMillis()) {
	lastFcuInfoLog = System.currentTimeMillis();
	logAtLevel.accept(status, forkChoice);
	}
	}

Would be good to have a single way to do it in a logging util. I can think of several places we could use it.

[diega]

Has the usage of a BurstFilter been analyzed for this use case?

[siladu]

I think @fab-10 may have looked into that or some similar feature of log4j. I agree that would be a neater approach and can't see a reason why we wouldn't want to use it for all logs

[fab-10]

I haven't yet looked at how to throttle this kind of logs, what I did was about summarizing the progress of the sync every tot seconds, this seems different, and I agree that something like the BurstFilter make sense here, since it could also be easily configurable.

[mark-terry]

From my investigation, BurstFilter doesn't appear to be specific enough to address this use case. My understanding is that it throttles the entire log level, whereas this functionality allows a specific (potentially spammy) log message to be throttled. Is my understanding of BurstFilter correct, or is it able to be targeted to a class/method level?

A logging improvement via log4j configuration would likely also require the user to configure it.

[fab-10]

Change request to avoid creating a thread on very log call. But if possible evaluate the usage of a BurstFilter for throttling logs

[mark-terry]

Will review BurstFilter. 👍