feat(worker): seal block early if we're over target block time

[Thegaram]

1. Purpose or design rationale of this PR

If we're over the target block time, short-circuit block packing and leave transactions to the next block.

This is a short-term fix to make the fork block more predictable.

2. PR title

Your PR title must follow conventional commits (as we are doing squash merge for each PR), so it must start with one of the following types:

• feat: A new feature

3. Deployment tag versioning

Has the version in params/version.go been updated?

• This PR doesn't involve a new deployment, git tag, docker image tag, and it doesn't affect traces
• Yes

4. Breaking change label

Does this PR have the breaking-change label?

• This PR is not a breaking change
• Yes

[omerfirmak]

Small q; do empty blocks need any special treatment?

[HAOYUatHZ]

we return instead of break in the loop. are we comfortable with skipping

	if !w.isRunning() && len(coalescedLogs) > 0 {
		// We don't push the pendingLogsEvent while we are mining. The reason is that
		// when we are mining, the worker will regenerate a mining block every 3 seconds.
		// In order to avoid pushing the repeated pendingLog, we disable the pending log pushing.

		// make a copy, the state caches the logs and these logs get "upgraded" from pending to mined
		// logs by filling in the block hash when the block was mined by the local miner. This can
		// cause a race condition if a log was "upgraded" before the PendingLogsEvent is processed.
		cpy := make([]*types.Log, len(coalescedLogs))
		for i, l := range coalescedLogs {
			cpy[i] = new(types.Log)
			*cpy[i] = *l
		}
		w.pendingLogsFeed.Send(cpy)
	}
	// Notify resubmit loop to decrease resubmitting interval if current interval is larger
	// than the user-specified one.
	if interrupt != nil {
		w.resubmitAdjustCh <- &intervalAdjust{inc: false}
	}
	return false, circuitCapacityReached

[Thegaram]

we return instead of break in the loop. are we comfortable with skipping

Good question. This code does not seem super relevant, but skipping it might return in some difference in how we expose pending blocks. Changed to break in 91627fb to be more consistent with the original behaviour.

Small q; do empty blocks need any special treatment?

I added the w.current.tcount > 0 condition to make sure we always make some progress processing transactions. It is possible that we keep processing and skipping transactions, but this does not seem to happen often in practice.