feat: put the log in the volume, so the container can be read-only

/var/log/letsencrypt was the only thing this image wrote outside its volumes,
and it is what stopped `read_only: true` from working. --logs-dir moves it to
/etc/letsencrypt/logs, beside the account key and the renewal config it
already keeps there.

The second gain is the one that matters more here. This is the service whose
breakage does not announce itself: a renewal that stops working is an expired
certificate sixty days later, and the log is what says why. On the root
filesystem it died with every container the registry replaced; in the volume
it outlives them.

Nothing else about the container needs to change to be confined. It never
changes user, the files it touches are its own, the ACME challenge is served
on 380 rather than a privileged port, and the HAProxy runtime socket it writes
to is group-owned by root -- so it reaches it by permission rather than by
CAP_DAC_OVERRIDE, and `cap_drop: ALL` takes nothing away. Measured on the live
relay: no file under /etc/letsencrypt or /etc/certificates is owned by anyone
but root, and the socket is srw-rw---- 1001:0.

Both READMEs say what a caller should set now, stop_grace_period included --
the entrypoint has asked for that one since it was written.

README.ru-RU.md

@@ -179,3 +179,13 @@ docker push registry.bitdeals.org/certbot
   выпуска на один домен в них засчитываются; проверяйте изменения на
   `--server https://acme-staging-v02.api.letsencrypt.org/directory`, прежде чем
   оставлять цикл повторять их каждые 12 часов.
+- **Ни одна capability здесь не нужна, а после `--logs-dir` не остаётся и
+  записи за пределы томов.** Контейнер не меняет пользователя, трогает только
+  свои файлы, а ACME-челлендж отдаёт на порту 380, а не на привилегированном,
+  поэтому `cap_drop: ALL` ему ничего не стоит. Исключением был журнал:
+  `/var/log/letsencrypt` на корневой файловой системе. Теперь он пишется в том
+  `letsencrypt`, рядом с остальным состоянием, и именно это делает возможным
+  `read_only: true` и сохраняет журнал неудавшегося продления после замены
+  контейнера. Задайте сервису и `stop_grace_period`: сигнал, пришедший во время
+  выпуска, откладывается до конца прохода, а выпуск умеет тянуться дольше
+  десяти секунд, которые даёт docker.