Point in Time should handle security on aliases

[jimczi]

In #61062 we introduced a new feature called PIT that allows to reuse the same context on multiple queries.
We've decided to merge the feature in advance but there is still one thing that we need to fix/decide. The PIT relies on the concrete index names that were resolved when the PIT was created. That allows to keep the scope of a PIT to only indices that existed when the PIT was created but that makes the security on aliases more challenging. Today we allow aliases to have different permissions than their targeted indices. Even though this feature is deprecated in security at the moment, it is unclear if we'll remove it in the future. So for PIT, we've decided to disallow the creation if an alias with a different permission is used in the creation request. This issue is a placeholder to ensure that we implement this protection before 7.10.
That should be temporary until the @elastic/es-security team revises the plan to un-deprecate or to remove this problematic use case definitely. If the decision is to un-deprecate we'll of course need to support the use case in PIT but that decision can wait after 7.10 is released.

[elasticmachine]

Pinging @elastic/es-search (:Search/Search)

[elasticmachine]

Pinging @elastic/es-docs (>docs)

[jimczi]

We discussed offline with @albertzaharovits and decided to document the fact that PITs will handle security at the concrete index level. If an alias is used to create a PIT, it is replaced by the concrete indices that it targets at the time when the PIT is created. These concrete indices are the one that we expose when the PIT is used in a search request so security will always resolve from the concrete list. This is consistent with the overall plan regarding alias security since we'll disallow aliases with different permissions in 8.0.