Rewriteable#rewriteAndFetch may complete its listener on a transport thread

[idegtiarenko]

While adding additional assertCurrentThreadPool in ES|QL code we noticed that after executing

elasticsearch/x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/expression/function/fulltext/QueryBuilderResolver.java

Lines 50 to 54 in 8486a63

	Rewriteable.rewriteAndFetch(
	new FunctionsRewriteable(plan),
	queryRewriteContext(services, indexNames(plan)),
	listener.delegateFailureAndWrap((l, r) -> l.onResponse(r.plan))
	);

from the SEARCH threadpool, a listener (and everything happening after) it could end up on a wide variety of threads including transport, see

elasticsearch/x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/session/EsqlSession.java

Lines 201 to 207 in e0296d0

	assert ThreadPool.assertCurrentThreadPool(
	TcpTransport.TRANSPORT_WORKER_THREAD_NAME_PREFIX,
	ThreadPool.Names.SYSTEM_READ,
	ThreadPool.Names.SEARCH,
	ThreadPool.Names.SEARCH_COORDINATION,
	MachineLearning.NATIVE_INFERENCE_COMMS_THREAD_POOL_NAME
	);

I believe it is not expected. If it is, it would be ideal to document it so that users of this api are aware and fork back to the correct thread pool.

[elasticsearchmachine]

Pinging @elastic/es-search (Team:Search)

[benwtrent]

rewriteAndFetch ending on transport seems like a really bad thing.

[elasticsearchmachine]

Pinging @elastic/es-search-relevance (Team:Search Relevance)