refactor(smoke): ограничен по времени опрос keeper, уточнены формулировки

- Зачем:
  - горячее ревью: перевезённая проверка keeper потеряла привычку файла
    ограничивать обращения к контейнерам по времени и глушить их ошибки.
- Что:
  - опрос keeper идёт через keeper_exec с timeout 20s и тихим stderr,
    в отчёте об отказе пустой ответ назван словами.
  - комментарий к проверке и абзац README переписаны на проверяемое
    утверждение: настройки объявлены в compose.yaml, смоук спрашивает,
    дошли ли они до процесса.
  - в пробнике ClickHouse ожидаемой строке возвращено имя expected_rows.
- Проверка:
  - make config-test, make smoke, make smoke-cluster; отдельно проверено,
    что на паузе keeper проверка краснеет, а не виснет.

README.md

@@ -64,8 +64,8 @@ Superset, создаёт администратора и импортирует
 
 `make smoke` проверяет зависимости машины, здоровье контейнеров, устройство
 keeper, Kafka через порт машины, три цели Prometheus, источник Grafana,
-компоненты Airflow, ручной запуск пробников `test_clickhouse`
-и `test_kafka`, метаданные и подключение Superset. Первый пробник создаёт
+компоненты Airflow, ручной запуск пробников `test_clickhouse` и `test_kafka`,
+метаданные и подключение Superset. Первый пробник создаёт
 таблицы на обеих нодах и читает через `Distributed` на ноде 2 строку из
 локальной таблицы ноды 1. Второй пишет в Kafka и читает свой маркер. В конце
 проверка спрашивает у Docker, не убивало ли ядро что-нибудь в долгоживущих
@@ -74,13 +74,14 @@ keeper, Kafka через порт машины, три цели Prometheus, ис
 Временный топик проверки с машины и запуски DAG удаляются;
 постоянный топик пробника сохраняется, а старые записи чистит Kafka.
 
-Про здоровье контейнеров честно будет сказать так: сразу после `make up --wait`
-эти одиннадцать проверок повторяют то, чего Compose уже дождался, — у каждой
-долгоживущей службы есть своя `healthcheck`. Оставлены они потому, что первый
-вопрос к стенду всё равно «всё ли живо», и ответ на него стоит меньше секунды.
-Устройство keeper — другое дело: он работает от пользователя `clickhouse`, с
-пределом в 262144 открытых файла и своим каталогом координации. Здоровым он
-выглядит и без этого, а грабли тут настоящие.
+Одиннадцать проверок здоровья сразу после `make up --wait` повторяют то, чего
+Compose уже дождался: у каждой долгоживущей службы есть своя `healthcheck`.
+Оставлены они потому, что первый вопрос к стенду всё равно «всё ли живо», а
+ответ на него стоит меньше секунды. Устройство keeper — другое дело: он должен
+работать от пользователя `clickhouse`, с пределом в 262144 открытых файла и со
+своим томом под данные. Всё это объявлено в `compose.yaml`, но здоровым keeper
+выглядит и без этого, поэтому смоук спрашивает у живого контейнера, дошли ли
+объявленные настройки до процесса.
 
 `make smoke-cluster` запускает отдельную глубокую проверку ClickHouse: описание
 кластера, макросы, связь с keeper, `ReplicatedMergeTree`, `Distributed`, очередь