`ensureShardSearchActive` may complete its listener on a refresh thread

[DaveCTurner]

If a shard is not search-active then the listener passed in to IndexShard#ensureShardSearchActive may be converted into a refresh listener and completed at the end of the refresh on the thread which performs the refresh. This will sometimes be an indexing thread (or occasionally a thread involved in recovery).

Mostly these listeners look to be relatively lightweight, typically forking elsewhere almost straight away, but there's a couple of places where that isn't the case:

1. We run the can-match phase on the refreshing thread here:

https://github.com/elastic/elasticsearch/blob/35cc35dda0e68d12bd28f6b732976d80c5642fbb/server/src/main/java/org/elasticsearch/search/SearchService.java#L485

2. We do all sorts of stuff on the refreshing thread here:

https://github.com/elastic/elasticsearch/blob/35cc35dda0e68d12bd28f6b732976d80c5642fbb/server/src/main/java/org/elasticsearch/search/SearchService.java#L953-L973

I'm not really qualified to say whether these things are ok to run on a write/recovery thread. Should we fork this work elsewhere? If not, could we at least add some comments to these places indicating that this is ok not to fork?

[elasticsearchmachine]

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

[elasticsearchmachine]

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