ESQL: Fix Driver creating status with a live list of operators

[ivancea]

DriverStatus is an immutable record created by the Driver. However, its components are not inherently immutable.

This PR fixes a live collection used by the Driver, that was being directly put into the status, leading to ConcurrentModificationExceptions when reading it (Through the Task list API, for example).

Some example errors:

java.util.ConcurrentModificationException
	at java.base/java.util.ArrayList$Itr.checkForComodification(ArrayList.java:1096)
	at java.base/java.util.ArrayList$Itr.next(ArrayList.java:1050)
	at org.elasticsearch.compute.operator.DriverStatus.toXContent(DriverStatus.java:134)
	at org.elasticsearch.xcontent@9.2.0/org.elasticsearch.xcontent.XContentBuilder.value(XContentBuilder.java:993)
	at org.elasticsearch.xcontent@9.2.0/org.elasticsearch.xcontent.XContentBuilder.field(XContentBuilder.java:978)
	at org.elasticsearch.server@9.2.0/org.elasticsearch.tasks.TaskInfo.toXContent(TaskInfo.java:113)
	at org.elasticsearch.server@9.2.0/org.elasticsearch.action.admin.cluster.node.tasks.list.TaskGroup.toXContent(TaskGroup.java:63)
	at org.elasticsearch.server@9.2.0/org.elasticsearch.action.admin.cluster.node.tasks.list.TaskGroup.toXContent(TaskGroup.java:67)
	at org.elasticsearch.server@9.2.0/org.elasticsearch.action.admin.cluster.node.tasks.list.ListTasksResponse.lambda$groupedByParent$10(ListTasksResponse.java:183)

And:

java.util.ConcurrentModificationException
	at java.base/java.util.ArrayList$Itr.checkForComodification(ArrayList.java:1096)
	at java.base/java.util.ArrayList$Itr.next(ArrayList.java:1050)
	at org.elasticsearch.compute.operator.DriverStatus.documentsFound(DriverStatus.java:157)
	at org.elasticsearch.compute.operator.DriverStatus.toXContent(DriverStatus.java:129)
	at org.elasticsearch.xcontent@9.2.0/org.elasticsearch.xcontent.XContentBuilder.value(XContentBuilder.java:993)
	at org.elasticsearch.xcontent@9.2.0/org.elasticsearch.xcontent.XContentBuilder.field(XContentBuilder.java:978)
	at org.elasticsearch.server@9.2.0/org.elasticsearch.tasks.TaskInfo.toXContent(TaskInfo.java:113)
	at org.elasticsearch.server@9.2.0org.elasticsearch.action.admin.cluster.node.tasks.list.TaskGroup.toXContent(TaskGroup.java:63)
	at org.elasticsearch.server@9.2.0/org.elasticsearch.action.admin.cluster.node.tasks.list.TaskGroup.toXContent(TaskGroup.java:67)
	at org.elasticsearch.server@9.2.0/org.elasticsearch.action.admin.cluster.node.tasks.list.ListTasksResponse.lambda$groupedByParent$10(ListTasksResponse.java:183)

Also, this looks like the source of this issue, with another similar case:
Fixes #131564

[elasticsearchmachine]

Pinging @elastic/es-analytical-engine (Team:Analytics)

[elasticsearchmachine]

Hi @ivancea, I've created a changelog YAML for you.

[nik9000]

I'd probably do List.copyOf here, but this is fine.

I think it's worth a comment that we always update the statusOfCompletedOperators list in this thread, but we read it in many threads.

[ivancea]

Added the suggestion, and a test.

About the statusOfCompletedOperators, after this change, it's never read outside of the updateStatus()

[elasticsearchmachine]

💔 Backport failed

Status	Branch	Result
✅	9.1
❌	8.19	Commit could not be cherrypicked due to conflicts
❌	9.0	Commit could not be cherrypicked due to conflicts
❌	8.17	Commit could not be cherrypicked due to conflicts
❌	8.18	Commit could not be cherrypicked due to conflicts

You can use sqren/backport to manually backport by running backport --upstream elastic/elasticsearch --pr 132260

[nik9000]

Status Branch Result
✅ 9.1
❌ 8.19 Commit could not be cherrypicked due to conflicts
❌ 9.0 Commit could not be cherrypicked due to conflicts
❌ 8.17 Commit could not be cherrypicked due to conflicts
❌ 8.18 Commit could not be cherrypicked due to conflicts

Enjoy!