ticdc: Fix CPU surge problem in sorter

[hongyunyan]

What problem does this PR solve?

Issue Number: close #10738

What is changed and how it works?

The problematic code snippet here:

tiflow/cdc/processor/sourcemanager/sorter/pebble/event_sorter.go

Lines 466 to 482 in e5edb19

	for {
	for len(batch.Repr()) < batchCommitSize && time.Since(startToCollectBatch) < batchCommitInterval {
	select {
	case item := <-inputCh:
	handleItem(item)
	case <-s.closed:
	return
	default:
	}
	}
	batchCh <- &DBBatchEvent{batch, newResolved}
	batch = db.NewBatch()
	newResolved = spanz.NewHashMap[model.Ts]()
	startToCollectBatch = time.Now()
	}
	}

is a busy loop that continuously polls an input channel and does some work when an item is available.
The issue here is with the 'default' clause in the select statement. If there's no item available in the 'inputCh' channel, it will immediately continue to the next iteration instead of blocking until an item is available or the 's.closed' channel is closed. This could lead to high CPU usage as the loop is continuously running.

This PR replace the 'default' clause with a ticker. This will cause the goroutine to block when there's no work to do, reducing CPU usage.

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)
• No code

Questions

Will it cause performance regression or break compatibility?

Do you need to update user documentation, design documentation or monitoring documentation?

Release note

`None`.

[CharlesCheung96]

Please explain the backgorung in pr body

[codecov]

Codecov Report

Merging #10739 (ad6363f) into master (e5edb19) will increase coverage by 0.1057%.
Report is 3 commits behind head on master.
The diff coverage is 75.0000%.

Additional details and impacted files

Components	Coverage Δ
cdc	62.1357% <75.0000%> (+0.2112%)	⬆️
dm	51.2334% <ø> (-0.0081%)	⬇️
engine	63.3724% <ø> (-0.0212%)	⬇️

Flag	Coverage Δ
unit	57.6751% <75.0000%> (+0.1057%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

@@               Coverage Diff                @@
##             master     #10739        +/-   ##
================================================
+ Coverage   57.5694%   57.6751%   +0.1057%     
================================================
  Files           851        852         +1     
  Lines        126793     127027       +234     
================================================
+ Hits          72994      73263       +269     
+ Misses        48361      48324        -37     
- Partials       5438       5440         +2     

[CharlesCheung96]

should an empty batchEvent be ignored?

[hongyunyan]

I check whether batchEvent is empty in L395, because whether the batchEvent is empty, we have to update resolved ts.

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: asddongmen, CharlesCheung96

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [CharlesCheung96,asddongmen]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[ti-chi-bot]

[LGTM Timeline notifier]

Timeline:

• 2024-03-08 06:06:49.540524682 +0000 UTC m=+406436.562771072: ☑️ agreed by asddongmen.
• 2024-03-11 02:05:03.048339963 +0000 UTC m=+651130.070586351: ☑️ agreed by CharlesCheung96.