Add ?wait_for_active_shards=default

[DaveCTurner]

Today you cannot explicitly indicate that an operation should use the
usual behaviour of waiting for active shards according to the underlying
index setting. This is a problem for the close index API which has a
default of none in 7.x for BWC reasons (see #33888), but the usual
behaviour in 8.0: you cannot today opt-in to the 8.0 behaviour with this
parameter.

This commit adds support for the literal value default for the
wait_for_active_shards query parameter.

Relates #66419

[elasticmachine]

Pinging @elastic/es-core-features (Team:Core/Features)

[DaveCTurner]

I'm not convinced that default is the right word here, although that's what we use internally. The default for some APIs is different. Moreover POST index/_close?wait_for_active_shards=default is different from POST index/_close, which is kind of the point, but from the users' point of view that's a weird thing.

[tlrx]

LGTM. There are a bunch of places in Request objects that have the following javadoc:

Defaults to {@link ActiveShardCount#DEFAULT}, which will wait for one shard copy (the primary) to become active

Do you think you could update these docs like you did in the REST API specs?

[DaveCTurner]

I'm going to go a different route here and only make this change for the close index API. There are other places where default isn't the default which don't want to be changed like this.