doc: remove raft log processing from clustering.mg

It's obsolete as we are not going to implement raft_applier fiber
anymore.

docs/clustering.md

@@ -253,52 +253,6 @@ struct Instance {
 - Также ответ содержит параметр `box_replication`, который требуется для
   правильной настройки репликации.
 
-## Обработка записей Raft-журнала
-
-Последовательность состояний каждой отдельной записи в Raft-журнале
-можно описать так:
-
-```md
-`Persisted` → `Committed` → `Applied`
-```
-
-При добавлении в журнал (по правилам это делает лидер) запись получает
-статус `Persisted` и начинает реплицироваться (это асинхронно делает
-файбер `raft_main_loop` ). Когда кворум узлов подтверждает
-персистентность записи, она считается зафиксированной. Важно понимать,
-что статус `Committed` присваивается записи на основе совокупности
-полученной информации, а не какого-то конкретного действия.
-
- Конкретные действия по обработке той или иной записи выполняет
- отдельный поток `raft_applier`<!--([TODO](## "Пока что отдельного
- потока нет, но лучше бы был"))-->. Для каждой записи он выполняет
- обработчик `Op::on_commit()` и по завершении присваивает записи статус
- `Applied`. Важно помнить, что обновление статуса и сама операция могут
- выполняться не атомарно (если в `Op::on_commit()` происходит передача
- управления другому потоку — yield). В таком случае, следует
- позаботиться хотя бы об идемпотентности операции.
-
-Схема ниже иллюстрирует эту информацию.
-
-![Raft log](raft_log_curves.svg "Последовательность обработки записей в
-Raft-журнале")
-
-Стоит также помнить, что алгоритм Raft гарантирует лишь консистентность
-последовательности записей, но не конкретные сроки выполнения. Смена
-статусов на разных инстансах так или иначе происходит в разные моменты
-времени, и иногда эту очередность приходится учитывать в алгоритмах.
-Например, при корректном запланированном выводе инстанса из эксплуатации
-(graceful shutdown) может возникнуть ситуация, когда инстанс завершится
-слишком быстро, и его соседи могут ошибочно продолжать считать его
-голосующим. Причиной такой ситуации может быть критерий остановки,
-включающий ожидание коммита лишь локально на завершаемом инстансе, но не
-на других — это может стать причиной потери кворума в кластере.
-
-<!--  Ниже данная ситуация рассмотрена подробнее. -->
-
-<!-- Была у нас однажды такая история — шла разработка graceful shutdown. Тест (`test_joining.py::test_deactivation`) останавливал один из двух инстансов и проверял, что тот (назовем его i2) перестал быть голосующим. Иногда тест проходил нормально, но иногда падал — `i2` завершал работу раньше, чем `i1` получал от него подтверждение. При этом критерий остановки включал в себя ожидание коммита, но только локально на `i2`, а не на `i1`. Из-за этого `i1` терял кворум. -->
-
-
 ## Graceful shutdown
 
 Чтобы выключение прошло штатно и не имело негативных последствий,