Sending conflicting transactions when injecting faults may cause the node to become stuck in operation.

[sdjasj]

Describe the bug
After starting a four-node private chain, I conducted stress testing by sending conflicting transactions. At the same time, I controlled one node (node1) to undergo random crashes and restarts. After some time, it seems that transactions cannot be executed normally (the progress bar of the test is stuck, and the sent transactions cannot be processed). Upon checking the node logs, I found that the controlled node undergoing crashes seemed to be continuously requesting block synchronization with other nodes.

To Reproduce
Steps to reproduce the behavior:

1. Start four-node private chain using ./start_all.sh
2. Use the official stress testing tool or custom-written testing code to send conflicting transactions, and control one node to undergo random restarts.
3. After running for a while, the transaction processing gets stuck, and the controlled node that undergos random restarts remains continuously requesting block synchronization with other nodes.

Expected behavior
Even if one node keeps restarting, the other three nodes should still be able to process transactions normally, and it should not cause the transaction processing to get stuck.

Screenshots

Environment (please complete the following information):

• OS: Ubuntu 20.04
• ISCO BCOS Version 3.5.0

Additional context
This is the partial log from the controlled node that undergoes restarts

warning|2024-01-16 01:00:00.158879|0x000015342da65640|[BLOCK SYNC]Discontinuous block,topNumber=109,curNumber=107,expectedBlock=108,commitQueueSize=0,isSyncing=true,knownHighestNumber=119,node=ec9ab589...
warning|2024-01-16 01:00:00.359270|0x000015342da65640|[BLOCK SYNC]Discontinuous block,topNumber=109,curNumber=107,expectedBlock=108,commitQueueSize=0,isSyncing=true,knownHighestNumber=119,node=ec9ab589...
warning|2024-01-16 01:00:00.559744|0x000015342da65640|[BLOCK SYNC]Discontinuous block,topNumber=109,curNumber=107,expectedBlock=108,commitQueueSize=0,isSyncing=true,knownHighestNumber=119,node=ec9ab589...
warning|2024-01-16 01:00:00.760134|0x000015342da65640|[BLOCK SYNC]Discontinuous block,topNumber=109,curNumber=107,expectedBlock=108,commitQueueSize=0,isSyncing=true,knownHighestNumber=119,node=ec9ab589...
warning|2024-01-16 01:00:00.960769|0x000015342da65640|[BLOCK SYNC]Discontinuous block,topNumber=109,curNumber=107,expectedBlock=108,commitQueueSize=0,isSyncing=true,knownHighestNumber=119,node=ec9ab589...
warning|2024-01-16 01:00:01.161235|0x000015342da65640|[BLOCK SYNC]Discontinuous block,topNumber=109,curNumber=107,expectedBlock=108,commitQueueSize=0,isSyncing=true,knownHighestNumber=119,node=ec9ab589...
warning|2024-01-16 01:00:01.361651|0x000015342da65640|[BLOCK SYNC]Discontinuous block,topNumber=109,curNumber=107,expectedBlock=108,commitQueueSize=0,isSyncing=true,knownHighestNumber=119,node=ec9ab589...
warning|2024-01-16 01:00:01.563162|0x000015342da65640|[BLOCK SYNC]Discontinuous block,topNumber=109,curNumber=107,expectedBlock=108,commitQueueSize=0,isSyncing=false,knownHighestNumber=119,node=ec9ab589...

And all logs are below
20240116_022027.tar.gz

[bxq2011hust]

can you please use v3.7.2+ to run the test?