refactor(smoke): срезаны проверки стенда, не служащие менти

- Зачем:
  - проверок стало больше, чем продукта, и росли они из критериев приёмки,
    а не из учебной ценности (#56).
- Что:
  - удалены tests/dag-probes-unit.py, tests/stand-smoke-guards.sh,
    tests/stand-smoke-static.sh и tests/smoke-guards.sh вместе с целью
    make smoke-guards и запуском юнит-тестов в scripts/config-test.sh.
  - из scripts/stand-smoke.sh убран check_env_consistency, туда же переехал
    check_keeper_runtime; счёт проверок остался 25.
  - в пробниках свёрнуты функции _assert_*, комментарий про отложенный импорт
    переписан на причину из документации Airflow и продублирован в test_kafka.
- Проверка:
  - make config-test, make up, make smoke, make smoke-cluster.

README.md

@@ -44,6 +44,12 @@ make up
 make smoke
 ```
 
+`.env.example` — справочник, а не настройка: в нём перечислены все переменные,
+которые читает `compose.yaml`, с теми же значениями по умолчанию. Стенд его не
+читает и на согласованность не проверяет, поэтому расхождение с `compose.yaml`
+обнаружит только читатель. Меняя подстановку `${VAR:-значение}` в
+`compose.yaml`, поправьте образец тем же коммитом.
+
 Учётные данные Postgres и Grafana применяются при создании их томов.
 После первого запуска меняйте их только вместе с `make clean`: команда удалит
 все локальные данные стенда, а следующий `make up` создаст их с новыми
@@ -56,9 +62,9 @@ make smoke
 подготавливает администратора и подключение к `clickhouse-01`. Второй обновляет
 Superset, создаёт администратора и импортирует подключение к `clickhouse-02`.
 
-`make smoke` проверяет согласованность `.env.example` с Compose, зависимости
-машины, здоровье контейнеров, Kafka через порт машины, три цели Prometheus,
-источник Grafana, компоненты Airflow, ручной запуск пробников `test_clickhouse`
+`make smoke` проверяет зависимости машины, здоровье контейнеров, устройство
+keeper, Kafka через порт машины, три цели Prometheus, источник Grafana,
+компоненты Airflow, ручной запуск пробников `test_clickhouse`
 и `test_kafka`, метаданные и подключение Superset. Первый пробник создаёт
 таблицы на обеих нодах и читает через `Distributed` на ноде 2 строку из
 локальной таблицы ноды 1. Второй пишет в Kafka и читает свой маркер. В конце
@@ -68,17 +74,28 @@ Superset, создаёт администратора и импортирует
 Временный топик проверки с машины и запуски DAG удаляются;
 постоянный топик пробника сохраняется, а старые записи чистит Kafka.
 
+Про здоровье контейнеров честно будет сказать так: сразу после `make up --wait`
+эти одиннадцать проверок повторяют то, чего Compose уже дождался, — у каждой
+долгоживущей службы есть своя `healthcheck`. Оставлены они потому, что первый
+вопрос к стенду всё равно «всё ли живо», и ответ на него стоит меньше секунды.
+Устройство keeper — другое дело: он работает от пользователя `clickhouse`, с
+пределом в 262144 открытых файла и своим каталогом координации. Здоровым он
+выглядит и без этого, а грабли тут настоящие.
+
 `make smoke-cluster` запускает отдельную глубокую проверку ClickHouse: описание
 кластера, макросы, связь с keeper, `ReplicatedMergeTree`, `Distributed`, очередь
 распределённых DDL и очистку временных таблиц.
 
-`make config-test` проверяет Compose, синтаксис Bash и Python, малые проверки
-логики пробников и пробельные ошибки в diff без запуска стенда.
+`make config-test` проверяет Compose, синтаксис Bash и Python и пробельные
+ошибки в diff без запуска стенда.
 
-`make smoke-guards` сначала проверяет аварийную семантику кластерной проверки,
-а затем удаляет служебную таблицу пробника только на второй ноде и
-останавливает Prometheus с Kafka. Общая проверка должна назвать Prometheus и
-оба пробника, после чего завершиться с ошибкой. В конце стенд восстанавливается.
+Правило, которое стоит держать в голове, правя любую из этих проверок:
+**проверка, которая не умеет краснеть, бесполезна.** Проверка, никогда не
+видевшая своей поломки, доказывает только то, что она умеет печатать «ЗЕЛЁНО».
+Убедиться дешевле всего руками: сломайте то, что она стережёт — остановите
+`prometheus`, удалите служебную таблицу пробника на второй ноде, — и посмотрите,
+покраснеет ли прогон и назовёт ли виновника. Не покраснел — проверка не
+работает, и чинить надо её, а не стенд.
 
 ### Какую проверку когда запускать
 
@@ -94,15 +111,8 @@ Superset, создаёт администратора и импортирует
   между службами, а не отдельные файлы: это интеграционная проверка.
 - `make smoke-cluster` — около минуты. Одна связь, зато до дна: межнодовое
   устройство ClickHouse.
-- `make smoke-guards` — около пяти минут, и отвечает на другой вопрос. Не
-  «работает ли стенд», а «умеют ли проверки падать»: она намеренно ломает стенд
-  и смотрит, покраснеет ли `make smoke` и назовёт ли виновника, потом чинит и
-  убеждается, что стенд снова зелёный. Отсюда и три прогона `make smoke`
-  внутри — до поломки, во время неё и после починки.
 
-Обычный рабочий цикл — `make config-test` и `make smoke`. `make smoke-guards`
-нужна тому, кто правит сами проверки или пробники: без неё легко завести
-проверку, которая зелена всегда.
+Обычный рабочий цикл — `make config-test` и `make smoke`.
 
 Остановить контейнеры без удаления данных можно командой `make down`. Для
 полного сброса с удалением всех именованных томов используйте `make clean`.