Add up-to-date docs for near-realtime search

[DaveCTurner]

The very first basic concept is that Elasticsearch is a near-realtime NRT search platform, but this is not defined in more depth in the reference manual. We receive questions (with low but nonzero frequency) of the form "I wrote a document and got an ack and then tried to search for it and it wasn’t there" and it'd be good if there was somewhere in the docs that answers this question so we could just share a link.

Today our options are:

• the relevant page of the definitive guide - this page contains good information, but the definitive guide as a whole is not up to date so it's risky to link new users there.

• the docs for the ?refresh option covers, or at least mentions, most of the ideas, except for...

• the POST _refresh API, but by default this is usually unnecessary because...

• index.refresh_interval defaults to 1s.

I think it'd be great if we could rework this into a single place in the reference docs that describes what NRT means as a concept, and how refreshes happen in Elasticsearch. Although it isn't really anything to do with replication, the replication overview is really more about the read and write models and I think that documenting the visibility semantics could fit here.

Additionally, it's not very clear that update-by-query and delete-by-query rely on searches, and therefore depend on which documents have been refreshed.

/cc @elastic/docs

[elasticmachine]

Pinging @elastic/es-distributed

[wchrisdean]

[doc issue triage]

[lockewritesdocs]

@DaveCTurner, I opened #57560 to address this issue. Regarding this statement:

Although it isn't really anything to do with replication, the replication overview is really more about the read and write models and I think that documenting the visibility semantics could fit here.

Are you hoping to condense the concepts of the read/write model into the topic for near-real time search? Namely describing how ES uses a replication group for writes and a coordinator node for reads, both of which can impact the refresh? I just want to ensure that I understand your intention.

[DaveCTurner]

I think a separate page is fine, no need to combine this with the replication overview. However, I think we should mention something about refreshes on the replication overview page too, to avoid any doubt that there must be a refresh in between writing a document and being able to read it.