Right now, the cluster health API can take parameters including: wait_for_active_shards and wait_for_relocating_shards. The idea with these parameters is that we may want to wait for the cluster health check to return only after certain conditions are met - for example, a certain number of active shards are found in the cluster (across all indices) or there are only a certain number of relocating shards in the cluster. Both of these parameters take a numeric value (integer).

With the introduction of wait_for_active_shards in place of write consistency level in #19454, it makes sense to have a single consistent usage of wait_for_active_shards. In the case of the replication operations, wait_for_active_shards is a string that can be all, default (whatever the default value is for the intended operation), or a numeric value as a string (e.g. 1, 2, etc).

The proposal is to have the cluster health API also use this "string" version of wait_for_active_shards, consistent with usage in the replication/write operations, where a numeric value can be set as well as all and default. In the case of the cluster health API, specifying all means that we check the current active shard count across all indices against the total shard count (primary + replicas, active + inactive) for all indices in the cluster.

In addition, to keep things consistent, the proposal is also to have wait_for_relocating_shards no longer take a number. Instead, it would make sense to have that as a boolean parameter wait_for_no_relocating_shards, which would just indicate whether we will wait for all relocating shards to complete or not. This is likely the only usage of the current wait_for_relocating_shards, as in general you are only concerned about the case of there being no more active relocations - otherwise the exact number of them is likely not something one is concerned with when checking cluster health. Also, all of our test cases only use 0 for the wait_for_relocating_shards` value right now.