Security: reduce garbage during index resolution

[jaymode]

The IndexAndAliasesResolver resolves the indices and aliases for each
request and also handles local and remote indices. The current
implementation uses the ResolvedIndices class to hold the resolved
indices and aliases. While evaluating the indices and aliases against
the user's permissions, the final value for ResolvedIndices is
constructed. Prior to this change, this was done by creating a
ResolvedIndices for the first set of indices and for each additional
addition, a new ResolvedIndices object is created and merged with
the existing one. With a small number of indices and aliases this does
not pose a large problem; however as the number of indices/aliases
grows more list allocations and array copies are needed resulting in a
large amount of garbage and severely impacted performance.

This change introduces a builder for ResolvedIndices that appends to
mutable lists until the final value has been constructed, which will
ultimately reduce the amount of garbage generated by this code.

Release note: Reduce the number of object allocations made by {security} when resolving the indices and aliases for a request.

[elasticmachine]

Pinging @elastic/es-security

[pcsanwald]

@jaymode as part of backporting this PR to 5.6.10, can you please backport the docs/changelog.asciidoc file and add an entry for this? It's the first changelog-worthy change in the 5.6.10 branch.

[jasontedor]

@jaymode as part of backporting this PR to 5.6.10, can you please backport the docs/changelog.asciidoc file and add an entry for this?

Two comments:

• Backporting the existence of the changelog should be a separate change from this one, if it is needed (see the next comment)
• We should verify with the docs team that we are going to use the changelog mechanism for all releases going forward including 5.6.x releases, not only 6.3 or 6.4 and forward?

[jasontedor]

A third comment, this change wouldn't be backported to 5.6 in this repository, that will happen in another repository since X-Pack is not open prior to 6.3.

[pcsanwald]

ok, I discussed earlier with @rjernst, as he pointed out that using the changelog could be a good way of assessing when we have enough critical mass to actually cut a release for 5.6.10. We don't yet have anything else merged for 5.6.10 that @rjernst thought we should include in changelog, and that's why thought this change would be a good opportunity to add.

@debadair and @lcawl, do you have concerns around using changelog for 5.x releases?

[jaymode]

If we decide to have a changelog file in the 5.6 branch of this repo, I'll happily open another PR that adds the file. I also know that this change needs a changelog entry

[lcawl]

In 5.6, the X-Pack release notes are published here: https://www.elastic.co/guide/en/x-pack/5.6/xpack-change-list.html (from files in a private repo). I can help copy the appropriate content into that release notes file.

[pcsanwald]

I agree with @rjernst that it would be nice to track 5.6.x work with a changelog, so I'd vote for having it in the other repo, once this change is merged and we have something to add to it.

[tvernum]

LGTM

[jaymode]

@pcsanwald would you mind taking a look at the changelog entry in this PR?

[pcsanwald]

@jaymode your addition looks fine, but in testing this out, I did find a bug in the CHANGELOG itself, and I've issued PR #30269 to fix.