Use a queue for node create/update indexing

Thirteen years later there might be a way to do this in a way that the search index would be immediately indexed on sites with automated cron, while faster for sites running queues on a different schedule to cron too, but it'll need ✨ Add an 'instant' queue runner Needs work first. Postponing on that.

Changes committed. Tests cases will pass only after ✨ Add an 'instant' queue runner Needs work is accepted / merged to 11.x / and updating the fork.

Setting to NR for reviewing the code changes.

Not sure I'm seeing the need to create performUpdateIndex, unless just from the queueworker. Any BC concern of this breaking existing code now that this code is in a new function?

Probably can be postponed though on the issue mentioned in #102.

performUpdateIndex indexes the given nids. Alternate is to use the updateIndex function in the queue. However this function does a left join on node to determine all the new nodes. This is very expensive operation on large sites. To avoid this expensive query updateIndex was refactored and performUpdateIndex was created. The queue runner invokes performUpdateIndex as the nid is already known saving an expensive db call.

I don't see any risk from BC perspective since it accepts the nids from the updateIndex function does the same steps as before.

Splitting the method into two looks good, we need to make sure the queue worker does minimal work.

I left a couple of comments on the MR. For me this could be committed independently of ✨ Add an 'instant' queue runner Needs work . It wouldn't result in instant search indexing until we have the other issue, but the two issues don't have any hard dependencies on each other otherwise.

Changing the NR for MR responses.

Related issue #3197264: Node searches fail if index is not complete, and users do not know why → . If the node indexing is being moved entirely to queues, then this scenario also needs to be handled.

We won't be able to move all node indexing to queues - at least when search is enabled, we need to index every node in the system, which needs the current search index watermark approach.

Tried cleaning up issue summary but could use 2nd pair of eyes. Original post mentioned something about a new setting but believe that's not the case anymore

Current MR is still marked as draft and appears to have a test failure.

Functionality is dependent on ✨ Add an 'instant' queue runner Needs work as mentioned in #102 → . Once that's Fixed and tests pass, will remove the draft on MR.