raftstore: enlarge leader-transfer-max-log-lag (#9592)
raftstore: enlarge leader-transfer-max-log-lag (#9592)

Signed-off-by: gengliqi <4622f8b79692f84595f46115884c6853b7a74a12@gmail.com>


### What problem does this PR solve?

Problem Summary:
The meaning of `leader-transfer-max-log-lag` has already been changed by https://github.com/tikv/tikv/pull/6539.
For now, it means the difference value between the leader's last log index and the follower's last applied index.
On the basis of implementation, we get the follower's last applied index through an RPC then we get the leader's last log index.
There are many gaps between this process. 
1. the applied index in peer fsm may be smaller than the real one in its corresponding apply fsm
2. the network latency
3. some logs may be proposed after sending the query RPC to this follower

So the follower's last applied index may be much larger when we calculate the difference value.

It thus appears that the default value of `leader-transfer-max-log-lag`(10) is too small which leads to many failures of leader transfer.

I test the value of 128 and the failure is much less than before.
* I test 256 and there is almost no failure. But maybe it's too large.

Maybe we should find a more scientific approach to solve this problem later.

### What is changed and how it works?

What's Changed:
Change the default value of `leader-transfer-max-log-lag` to 128.

### Related changes

- PR to update `pingcap/docs`/`pingcap/docs-cn`:
- PR to update `pingcap/tidb-ansible`:
- Need to cherry-pick to the release branch

Tests <!-- At least one of them must be included. -->

- No code

Side effects

- No

### Release note <!-- bugfixes or new feature need a release note -->
* Change the default `leader-transfer-max-log-lag` to 128 to increase the success rate of leader transfer 
c4pt0r/tikv,BusyJay/tikv,BusyJay/tikv,BusyJay/tikv,BusyJay/tikv