Un-hardcode SecurityIndexManager to handle generic indices

[albertzaharovits]

SecurityIndexManager is hardcoded to handle only the .security-.security-7 alias-index pair.
This commit removes the hardcoded bits, so that the SecurityIndexManager can be reused for other indices, such as the planned token index (.security-tokens-7).

[elasticmachine]

Pinging @elastic/es-security

[tvernum]

I'm good with this as a step forward, but I think we're going to need to split the class again (see #30526) if we want to manage multiple indices.

We can tackle that problem when we get to it, but I think it's going to get messy when we have 2 instances of this class being injected into constructors of other classes (and there's a few of them), and calls to checkIndexVersionThenExecute (etc) will need to make sure they're hitting the correct instance for the index that they're after.

Even something simple like making the injected component be

public class SecurityIndices() {

   public SecurityIndexManager() mainIndex() { ... }
   public SecurityIndexManager() tokenIndex() { ... }
}

We don't need to decide now, but my prediction is that when you have two SecurityIndexManager instances floating around, we'll want to do something to bring a bit more clarity to it.

[albertzaharovits]

You're right Tim that having a SecurityIndexManager for the tokens index is confusing, especially when you have another SecurityIndexManager for the security index floating around.

My plan was to have the two of them hidden behind static getters similar to your suggestion, although I don't know how it would play out with #30526 (comment) (if it is still relevant). Another thing to consider is that there would not be both "floating around" because the tokens one would be buried inside the TokenService when that's enabled ... possibly... I'll see to it in the follow-up.