Prior to SERVER-53920, the resharding coordinator had chosen all of the recipient shards reaching RecipientStateEnum::kSteadyState as a somewhat arbitrary point for the resharding operation before it would inform the donor shards to write the final resharding oplog entry. Now that the resharding coordinator periodically polls the recipient shards to get an estimate of how much time remains before they'd be completely caught up to all of the donor shards, there is no benefit to having this distinction in the recipient shards.

Additional note: RecipientStateEnum::kSteadyState has generally been associated with the idea that the recipient shard's copy of the data is consistent but stale. This is mostly true and is specifically untrue in the cases where the recipient shard undergoes replication rollback and relies on idempotency for its copy of the data to become consistent again.