[improvement](sync version) fe sync version with be

[yujun777]

Proposed changes

pick: #25236

fe should sync replica's version with be's report:

I. In some cases, replica version of fe may greater than be's report version due to program bugs. If there's no write later, fe replica's last failed version will always be -1. And this replica couldn't be repair.

To fix these, if fe's version > be's report version, after 5min, fe will mark this replica as missing versions. Later this replica can be repair;

II. In some other cases, it will cause case replica's version = partition's visible version = partition's committed version, and replica's last failed version = partition's + 1. case as follow:
a. suppose partition visible version = 10, committed version = 11, the committed txn version T is not published yet;
b. clone a replica A to B, after cloning, B's version = 10.
c. publish txn T, A version = 11. Also due to txn publish bug, B's version = 11 (PR #23706 has fix this);
d. publish another txn, A and B's version become 12;
e. now B's backend version is: [1, 10], [12, 12], it will report it missing version = 11; then fe will mark this replica's last failed version = version + 1 = 12 + 1 = 13;
f. fe will let B clone version 11 from A, after cloning, B will contains all the version. But Replica.updateVersion has bug,
if it found its version not change (12 -> 12)，it will not set replica's last failed version to -1.
Then later, B will always be: version = 12, last failed version = 13.

To Fix this problem, after cloning or when be report, if replica's version >= partition's commit version(more precise, replica's version = partition's commit version), and replica's last failed version > partition's commit (more precise, replica's last failed version = partition's commit version + 1), then we should set replica's last failed version to -1.

Also debug points add params.

Further comments

If this is a relatively large or complex change, kick off the discussion at dev@doris.apache.org by explaining why you chose the solution you did and what alternatives you considered, etc...

[yujun777]

run buildall

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[hello-stephen]

(From new machine)TeamCity pipeline, clickbench performance test result:
the sum of best hot time: 48.35 seconds
stream load tsv: 552 seconds loaded 74807831229 Bytes, about 129 MB/s
stream load json: 20 seconds loaded 2358488459 Bytes, about 112 MB/s
stream load orc: 65 seconds loaded 1101869774 Bytes, about 16 MB/s
stream load parquet: 32 seconds loaded 861443392 Bytes, about 25 MB/s
insert into select: 29.5 seconds inserted 10000000 Rows, about 338K ops/s
storage size: 17162545695 Bytes

[xiaokang]

run buildall

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"