Avoid HashMap construction on Grok non-match (#42444)

This change moves the construction of the result
HashMap in Grok.captures() into the branch that
actually needs it.

This probably will not make a measurable difference
for ingest pipelines, but it is beneficial to the
ML find_file_structure endpoint, as it tries out
many Grok patterns that will fail to match.

libs/grok/src/main/java/org/elasticsearch/grok/Grok.java

@@ -240,7 +240,6 @@ public final class Grok {
      */
     public Map<String, Object> captures(String text) {
         byte[] textAsBytes = text.getBytes(StandardCharsets.UTF_8);
-        Map<String, Object> fields = new HashMap<>();
         Matcher matcher = compiledExpression.matcher(textAsBytes);
         int result;
         try {
@@ -256,6 +255,7 @@ public final class Grok {
             // TODO: I think we should throw an error here?
             return null;
         } else if (compiledExpression.numberOfNames() > 0) {
+            Map<String, Object> fields = new HashMap<>();
             Region region = matcher.getEagerRegion();
             for (Iterator<NameEntry> entry = compiledExpression.namedBackrefIterator(); entry.hasNext();) {
                 NameEntry e = entry.next();
@@ -270,8 +270,10 @@ public final class Grok {
                     }
                 }
             }
+            return fields;
+        } else {
+            return Collections.emptyMap();
         }
-        return fields;
     }
 
     public static Map<String, String> getBuiltinPatterns() {