Allow population of Enrich indices to work with System Index protections

[gwbrown]

Enrich currently makes a reindex call to populate .enrich* indices. This is done in the context of the user executing the policy to ensure that DLS/FLS are correctly applied. However, this causes issues with the deprecation of access to System Indices in #60945 - in every other case, access to System Indices internally can be performed in the context of an xpack user, but because we need to make the reindex call in the Security context of the user, access to the .enrich* System Index must be done in the user's context as well.

In #60945 we have a hack to work around this and prevent unnecessary deprecation warnings, but that hack will not work when we cut over to enforcing access restrictions on System Indices.

This issue is to discuss options for resolving this with folks more familiar with Enrich.

[elasticmachine]

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

[gwbrown]

We discussed this in the core/features area sync today, and we concluded that the most likely solution is to see if it's possible to modify the Reindex operation to take separate Client objects for the input and output stages. This way, we could pass an OriginSettingClient in as the "output" client to allow access to the .enrich* indices, while still maintaining the appropriate context for the input. Taking a quick look at the code, this looks doable.

[jaymode]

I missed the previous update about the discussion but had a similar idea and worked on a poc. Overall, adding a second client is fairly straightforward, see master...jaymode:enrich_sys_idx_poc