Set ChainService process_block channel size to zero

[eval-exec]

What problem does this PR solve?

On the develop branch, the ChainService's process_block channel has a capacity of DEFAULT_CHANNEL_SIZE(32), but it does not provide any benefit for ckb-sync or ckb-chain:

ckb/chain/src/chain.rs

Line 225 in 149b5c5

let (process_block_sender, process_block_receiver) = channel::bounded(DEFAULT_CHANNEL_SIZE);

In a scenario where ckb-sync sends a block to ChainService through ChainController::process_block, and at the same time, ChainService receives a Ctrl-C exit signal.
Then ChainService's process_block_sender have one ProcessBlockRequest in its buffer:

ckb/chain/src/chain.rs

Line 41 in 149b5c5

type ProcessBlockRequest = Request<(Arc<BlockView>, Switch), Result<bool, Error>>;

When self.process_block_sender and self.stop_receiver are ready at the same time, ChainService's select! may choose to execute self.stop_receiver:

ckb/chain/src/chain.rs

Lines 237 to 272 in 149b5c5

	select! {
	recv(process_block_receiver) -> msg => match msg {
	Ok(Request { responder, arguments: (block, verify) }) => {
	let instant = Instant::now();
	let _ = tx_control.suspend_chunk_process();
	let _ = responder.send(self.process_block(block, verify));
	let _ = tx_control.continue_chunk_process();
	if let Some(metrics) = ckb_metrics::handle() {
	metrics
	.ckb_block_process_duration
	.observe(instant.elapsed().as_secs_f64());
	}
	},
	_ => {
	error!("process_block_receiver closed");
	break;
	},
	},
	recv(truncate_receiver) -> msg => match msg {
	Ok(Request { responder, arguments: target_tip_hash }) => {
	let _ = tx_control.suspend_chunk_process();
	let _ = responder.send(self.truncate(&target_tip_hash));
	let _ = tx_control.continue_chunk_process();
	},
	_ => {
	error!("truncate_receiver closed");
	break;
	},
	},
	recv(signal_receiver) -> _ => {
	info!("ChainService received exit signal, exit now");
	break;
	}
	}

then the process_block_receiver will be dropped.

However, the process_block_sender is held by the Synchronizer's ChainController, and there is one ProcessBlockRequest in process_block_sender's buffer, causing the ChainController::internal_block_process to block indefinitely.

In that case, Synchronizer::received will block indefinitely at this point:

ckb/sync/src/synchronizer/mod.rs

Line 784 in 149b5c5

tokio::task::block_in_place(|| self.process(nc.as_ref(), peer_index, msg));

What is changed and how it works?

Related changes

• Set ChainService's process_block channel capacity size to 0.

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)
• No code ci-runs-only: [ quick_checks,linters ]

Side effects

• None

Release note

Title Only: Include only the PR title in the release note.

[doitian]

Will it have any negative impact?

[eval-exec]

Will it have any negative impact?

There should be no negative impact.

[driftluo]

ref：crossbeam-rs/crossbeam#1102
this is a bug for crossbeam channel