[HDFS-16064] backporting HDFS-16064. Determine when to invalidate corrupt replicas based on number of usable replicas (#4410)

[zz12341]

Description of PR

HDFS-16064 fixed an issue where decommissioning replicas were not counted as usable replicas, which caused decom to stuck forever in the case of small clusters. We are seeing the same issue on 2.10, and thus backporting the changes.

How was this patch tested?

For code changes:

• [ x] Does the title or this PR starts with the corresponding JIRA issue id (e.g. 'HADOOP-17799. Your PR title ...')?
• Object storage: have the integration tests been executed and the endpoint declared according to the connector-specific documentation?
• If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
• If applicable, have you updated the LICENSE, LICENSE-binary, NOTICE-binary files?

[shahrs87]

@zz12341 Why we want these changes? I don't see it in the original patch here.

[zz12341]

I was originally trying to make it in sync with what trunk branch is doing: https://github.com/apache/hadoop/pull/4410/files#diff-305ecf45a0f0708849b5e3c0d21a56c681db3a1497e52a19ef24939278dc99feL1922-R1926

Let me revert this change

[shahrs87]

Suggested change

	numberOfReplicas.liveReplicas() >= minReplication;
	numUsableReplicas >= minReplication;

[shahrs87]

@zz12341 branch-2.10 is the active branch for 2.10 (not branch-2.10.0). You can see all the active branches here.

[shahrs87]

@zz12341 This change in BlockManager#addStoredBlock is missing from the original patch? #4410

[shahrs87]

[HDFS-16064] backporting HDFS-16064. Determine when to invalidate corrupt replicas based on number of usable replicas (#4410) #6437

@zz12341 Keep the title and the commit message same as #4410. We shouldn't add backporting keyword in the title and commit message.

[github-actions]

We're closing this stale PR because it has been open for 100 days with no activity. This isn't a judgement on the merit of the PR in any way. It's just a way of keeping the PR queue manageable.
If you feel like this was a mistake, or you would like to continue working on it, please feel free to re-open it and ask for a committer to remove the stale tag and review again.
Thanks all for your contribution.