ESQL: Track memory in evaluators (elastic#133392) (elastic#133593)

If you write very very large ESQL queries you can spend a lot of memory
on the expression evaluators themselves. You can certainly do it in real
life, but our tests do something like:
```
FROM foo
| EVAL a0001 = n + 1
| EVAL a0002 = a0001 + 1
| EVAL a0003 = a0002 + 1
...
| EVAL a5000 = a4999 + 1
| STATS MAX(a5000)
```

Each evaluator costs like 200 bytes a pop. For thousands of evaluators
this adds up. So! We have to track it.

Nhat had suggested charging a flat 200 bytes a pop. I thought about it
and decided that it'd be pretty easy to get the actual size. Most of the
evaluators are generated and it's a fairly small generated change to
pick that up. So I did.

We *do* build the evaluators before we cost them, but that's fine
because they are very very small. So long as we account for them, I
think it's safe.

Author: nik9000

benchmarks/src/main/java/org/elasticsearch/benchmark/compute/operator/AggregatorBenchmark.java

@@ -643,6 +643,11 @@ public Block eval(Page page) {
                 return mask;
             }
 
+            @Override
+            public long baseRamBytesUsed() {
+                return 0;
+            }
+
             @Override
             public void close() {
                 mask.close();

benchmarks/src/main/java/org/elasticsearch/benchmark/compute/operator/EvalBenchmark.java

@@ -132,7 +132,7 @@ public class EvalBenchmark {
     public String operation;
 
     private static Operator operator(String operation) {
-        return new EvalOperator(driverContext.blockFactory(), evaluator(operation));
+        return new EvalOperator(driverContext, evaluator(operation));
     }
 
     private static EvalOperator.ExpressionEvaluator evaluator(String operation) {

docs/changelog/133392.yaml

@@ -0,0 +1,5 @@
+pr: 133392
+summary: Track memory in evaluators
+area: ES|QL
+type: bug
+issues: []