[ML] Add an ML results index rollover endpoint

[elasticmachine]

Original comment by @droberts195:

The ML results index rollover endpoint will need to do the following:

• Take a results_index_name field as input (which can be shared for the default shared index)
• Check whether it's appropriate to roll that particular index - this can be done using the dry_run argument of the standard rollover API
• If it is then create the new empty index
• Adjust all the read aliases for jobs that have the chosen results_index_name to include the newly created index
• Adjust all the write aliases for jobs that have the chosen results_index_name to point at the newly created index
• All the alias updates can be done atomically in one request

[elasticmachine]

Original comment by @droberts195:

It seems that index lifecycle management has almost exactly the same problem and is solving it as specified #30061. That solution won't quite work for us at the moment, as our read-only aliases aren't necessarily wildcarded. But we might be able to hugely simplify the logic needed to add the functionality proposed in this issue by making our read-only aliases always wildcarded.

[elasticmachine]

Original comment by @droberts195:

The thinking in #30061 has moved on. I think what is proposed in #30061 (comment) helps us a lot.

[droberts195]

Where a job is sharing a results index and the number of results documents for the job goes above a threshold, we should switch future results over to a dedicated results index to ensure that the number of results in the shared index is never huge. This implies the read alias for getting the job's results needs to span both a shared and dedicated results indices.

This requirement is driven by the customer requirement described in #30075 (comment), as it would allow the optimisation of deleting the whole results index rather than doing a delete-by-query to be used on the non-shared results.