### Elasticsearch Version

8.6.0

### Installed Plugins

_No response_

### Java Version

_bundled_

### OS Version

Docker

### Problem Description

When testing datemath with complex date strings, I found that some worked and some didn't. I narrowed it down to the existence of the `|` pipe character in the string.

@dakrone seems to think this may be due to how the `IndexNameExpressionResolver` works differently for security-enabled vs. non-security-enabled clusters.

### Steps to Reproduce

## Security Disabled Cluster
```
curl -XGET 'http://localhost:9200/%3Cdatemath-%7B2001-01-01-13%7C%7C%2B1h%2Fh%7Byyyy-MM-dd-HH%7C-07%3A00%7D%7D%3E'
{"error":{"root_cause":[{"type":"illegal_argument_exception","reason":"Cross-cluster calls are not supported in this context but remote indices were requested: [<datemath-{2001-01-01-13||+1h/h{yyyy-MM-dd-HH|-07:00}}>]"}],"type":"illegal_argument_exception","reason":"Cross-cluster calls are not supported in this context but remote indices were requested: [<datemath-{2001-01-01-13||+1h/h{yyyy-MM-dd-HH|-07:00}}>]"},"status":400}%
```

## Security Enabled Cluster

```
curl -XGET -u sample -p 'https://secure.cluster.io/%3Cdatemath-%7B2001-01-01-13%7C%7C%2B1h%2Fh%7Byyyy-MM-dd-HH%7C-07%3A00%7D%7D%3E'
Enter host password for user 'sample':
{"error":{"root_cause":[{"type":"index_not_found_exception","reason":"no such index [datemath-2001-01-01-14]","index_uuid":"_na_","index":"datemath-2001-01-01-14"}],"type":"index_not_found_exception","reason":"no such index [datemath-2001-01-01-14]","index_uuid":"_na_","index":"datemath-2001-01-01-14"},"status":404}%
```

### Logs (if relevant)

_No response_
server/src/main/java/org/elasticsearch/cluster/metadata/IndexNameExpressionResolver.java
.stream()
                    .filter(indexAbstraction -> indexAbstraction.getType() == Type.DATA_STREAM)
                    .filter(
                        indexAbstraction -> indexAbstraction.isSystem() == false
                            || context.systemIndexAccessPredicate.test(indexAbstraction.getName())
                    );
                if (context.getOptions().expandWildcardsHidden() == false) {
                    dataStreamsAbstractions = dataStreamsAbstractions.filter(indexAbstraction -> indexAbstraction.isHidden() == false);
                }
                
                Set<String> resolvedIncludingDataStreams = expandToOpenClosed(context, dataStreamsAbstractions).collect(Collectors.toSet());
                resolvedIncludingDataStreams.addAll(resolvedExpressions);
                return resolvedIncludingDataStreams;
            }
        }
        /**
         * Returns all the existing resource (index, alias and datastream) names that the {@param expressions} list resolves to.
         * The passed-in {@param expressions} can contain wildcards and exclusions, as well as plain resource names.
         * <br>
         * The return is a {@code Collection} (usually a {@code Set} but can also be a {@code List}, for performance reasons) of plain
         * resource names only. All the returned resources are "accessible", in the given context, i.e. the resources exist
         * and are not an alias or a datastream if the context does not permit it.
         * Wildcard expressions, depending on the context:
         * <ol>
         *   <li>might throw an exception if they don't resolve to anything</li>
         *   <li>might not resolve to hidden or system resources (but plain names can refer to hidden or system resources)</li>
         *   <li>might resolve to aliases and datastreams, and it could be (depending on the context) that their backing indices are what's
         * ultimately returned, instead of the alias or datastream name</li>
         * </ol>
         */