raise SQL thread startup timeout to 600s

The startup VACUUM of a large messages.dat exceeds the stock 60 s window,
and PyBitmessage then kills the daemon (os._exit). Since it dies mid-VACUUM
lastvacuumtime is never updated, so every later start repeats it and the
node stays down with its API not listening.

docker/Dockerfile

@@ -20,6 +20,28 @@ RUN git clone https://github.com/Bitmessage/PyBitmessage .
 # Install
 RUN pip2 install jsonrpclib .
 
+# Raise the SQL-thread startup timeout from the stock 60 s.
+#
+# PyBitmessage kills the daemon outright if the SQL thread is not ready within
+# sql_timeout seconds (class_objectProcessor.py -> os._exit(1)). The startup
+# VACUUM of a messages.dat that has grown to a few hundred MB does not fit in
+# 60 s, and since the process dies mid-VACUUM lastvacuumtime is never updated,
+# so every later start retries the same doomed VACUUM and the node never comes
+# back. Measured: 26 s for a 264 MB database on an idle host, and the last
+# start that did survive used 36 s of the 60.
+#
+# The greps are load-bearing: the clone above is unpinned, so if upstream ever
+# moves or renames the constant, a silent no-op sed would ship an image that
+# looks fixed and is not. Fail the build instead. The .pyc is refreshed because
+# at runtime /usr/local is root-owned while the daemon runs as bitmessage, so a
+# stale one can only be recompiled to memory on every start.
+RUN f=/usr/local/lib/python2.7/dist-packages/pybitmessage/helper_sql.py \
+ && grep -q '^sql_timeout = 60$' "$f" \
+ && sed -i 's/^sql_timeout = 60$/sql_timeout = 600/' "$f" \
+ && grep -q '^sql_timeout = 600$' "$f" \
+ && rm -f "${f}c" \
+ && python -c "import py_compile; py_compile.compile('$f')"
+
 FROM ubuntu:bionic
 
 EXPOSE 8442/tcp