A malicious node becomes a leader and set the view to a very large one, blocks cannot be processed

[fCorleone]

Describe the bug
I setup a group with 10 nodes. One of them are malicious one. First, the malicious node starts, and after that all the other nodes start. Then I start the press testing program to send transactions to the group. And it stuck here:

To Reproduce
Steps to reproduce the behavior:

1. setup 10 nodes
2. start press testing program
3. the bug occurs

Expected behavior
The system should not stuck and keep changing the view.

Screenshots

Environment (please complete the following information):

• OS: Ubuntu 20.04
• FISCO BCOS Version 3.0.0-rc2

Additional context
There maybe an integer overflow during the viewchange and the malicious node can always be the leader.

[cyjseagull]

The problem is triggered because the view overflows:

1. The loki node starts first and broadcasts a large viewchange message packet (view = int64_max) to other nodes;

2. After other nodes receive this message packet and find that the view is larger than their own view, they will trigger quick view switching, and try to switch to this view, and set toView to view+1. At this time, toView overflows and reset to 0;

3. After that, everyone basically maintained this largest view, resulting in an abnormal consensus.

We try to fix this issue by PR #2311