Update assertion in setResolvedIndexExpressionsIfUnset (elastic#138866)

Instead of fully suppressing the assertion due to the known issue, this
PR adds two more relaxed assertions so that we can be sure the issue
does not expand in future.

Relates: elastic#135799

Author: ywangd

x-pack/plugin/security/src/main/java/org/elasticsearch/xpack/security/authz/IndicesAndAliasesResolver.java

@@ -569,9 +569,15 @@ private static void setResolvedIndexExpressionsIfUnset(IndicesRequest.Replaceabl
                 + replaceable.getClass().getName()
                 + "]";
             logger.debug(message);
-            // we are excepting `*,-*` below since we've observed this already -- keeping this assertion to catch other cases
-            // If more exceptions are found, we can add a comment to above linked issue and relax this check further
-            // assert replaceable.indices() == null || isNoneExpression(replaceable.indices()) : message;
+            // Double authorization and hence index resolution can happen first in ServerTransportFilter and then in SecurityActionFilter.
+            // This cannot happen on the coordinating node since it does not involve ServerTransportFilter. Therefore, there should be no
+            // remote indices.
+            assert replaceable.getResolvedIndexExpressions().getRemoteIndicesList().isEmpty() && resolved.getRemoteIndicesList().isEmpty()
+                : message;
+            // Since the first resolution expands all wildcards, the second resolution is performed against concrete names.
+            // As a result, the resolved indices from the second resolution must be identical (most likely) or a subset of the
+            // resolved indices from the first resolution if the user's role changes in between the two authorizations.
+            assert replaceable.getResolvedIndexExpressions().getLocalIndicesList().containsAll(resolved.getLocalIndicesList()) : message;
         }
     }