[bugfix](fd) Recycle the segment file fds directly when delete stale rowset

[Lchangliang]

Proposed changes

Issue Number: close #xxx

When load frequently, BE will do compaciton frequently. And because of set enable_vertical_compaction is true, when doing vectical compaction, it will cache the segments in segment cache. When the stale rowset is evicted, the segment cache doesn't recycle the fds in time because the recycle is lazy. So it will make mistakes because of "Too many open file".
Fix by tow methods:

1. Recycle fds directly when delete stale rowsets.
2. Don't cache fd when doing vectical compaction.

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...

[Lchangliang]

run buildall

[github-actions]

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

[Lchangliang]

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: 46.07 seconds
stream load tsv: 538 seconds loaded 74807831229 Bytes, about 132 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: 31 seconds loaded 861443392 Bytes, about 26 MB/s
insert into select: 29.2 seconds inserted 10000000 Rows, about 342K ops/s
storage size: 17162196986 Bytes

[Lchangliang]

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: 47.17 seconds
stream load tsv: 513 seconds loaded 74807831229 Bytes, about 139 MB/s
stream load json: 20 seconds loaded 2358488459 Bytes, about 112 MB/s
stream load orc: 64 seconds loaded 1101869774 Bytes, about 16 MB/s
stream load parquet: 31 seconds loaded 861443392 Bytes, about 26 MB/s
insert into select: 29.4 seconds inserted 10000000 Rows, about 340K ops/s
storage size: 17162109471 Bytes

[yiguolei]

LGTM

[github-actions]

PR approved by at least one committer and no changes requested.

[github-actions]

PR approved by anyone and no changes requested.

[dataroaring]

LGTM