start adding documentation on updating mapping

[trinity-1686a]

Description

add documentation on the known limitations when updating a doc mapping

@rdettai i know you were surprised by a few things, please step in if you think I missed anything important
@fmassot you might have opinions on things to add too.

this is based on the expect stat of updates once all currently existing PR on the subject are merged

[github-actions]

On SSD:

Average search latency is 1.01x that of the reference (lower is better).
Ref run id: 3629, ref commit: 450f26a
Link

On GCS:

Average search latency is 0.986x that of the reference (lower is better).
Ref run id: 3630, ref commit: 450f26a
Link

[guilload]

Suggested change

	When you update a doc mapping for an index, Quickwit will restart indexing pipelines to take the changes into account. As both this operation and the document ingestion are asynchronous, you can't assume documents sent immediately after the update will necessarily use the new mapping nor that documents sent immediately before the update won't be indexed using the new doc mapping.
	When you update a doc mapping for an index, Quickwit will restart indexing pipelines to take the changes into account. As both this operation and the document ingestion are asynchronous, you can't assume documents sent immediately after the update will necessarily use the new mapping or documents sent immediately before the update will be indexed using the new doc mapping.

Removing the double negative.

[trinity-1686a]

i think won't was what i meant, if you send a document while there is a large queue in the wal, and then update the mapping, it is possible for the pipeline to be restarted before reaching that document, so it may be indexed with the newer mapping (or it may not, if the wal was short/empty).