fix: SQL statement expansion for plugin db_write hook

[m-schmoock]

I discovered this accidentally when using the tests/plugins/dblog.py
plugin on another testcase: tests/test_connection.py::test_fail_unconfirmed
There the plugin/hook crashes because it can't execute the statement:

{
  "jsonrpc": "2.0",
  "id": 34,
  "error": {
    "code": -32600,
    "message": "Error while processing db_write: unrecognized token: \"174WHERE\"",
    "traceback": "Traceback (most recent call last):\n  File \"/home/will/projects/lightning.git/contrib/pyln-client/pyln/client/plugin.py\", line 535, in _dispatch_request\n    result = self._exec_func(method.func, request)\n  File \"/home/will/projects/lightning.git/contrib/pyln-client/pyln/client/plugin.py\", line 520, in _exec_func\n    return func(*ba.args, **ba.kwargs)\n  File \"/home/will/projects/lightning.git/tests/plugins/dblog.py\", line 45, in db_write\n    plugin.conn.execute(c)\nsqlite3.OperationalError: unrecognized token: \"174WHERE\"\n"
  }
}

I used the following change to have the testcase execute the plugin:

diff --cc tests/test_connection.py
index 02780a233,02780a233..76789afa4
--- a/tests/test_connection.py
+++ b/tests/test_connection.py
@@@ -2351,8 -2351,8 +2351,11 @@@ def test_restart_many_payments(node_fac
  def test_fail_unconfirmed(node_factory, bitcoind, executor):
      """Test that if we crash with an unconfirmed connection to a known
      peer, we don't have a dangling peer in db"""
++    dbfile = os.path.join(node_factory.directory, "dblog.sqlite3")
++    opts={'plugin': os.path.join(os.getcwd(), 'tests/plugins/dblog.py'), 'dblog-file': dbfile}
++
      # = is a NOOP disconnect, but sets up file.
--    l1 = node_factory.get_node(disconnect=['=WIRE_OPEN_CHANNEL'])
++    l1 = node_factory.get_node(options = opts, disconnect=['=WIRE_OPEN_CHANNEL'])
      l2 = node_factory.get_node()
 
      # First one, we close by mutual agreement.

Update: I pulled in @cdecker changes from #4092 that fixes this for another location and adds a TEST_CHECK_DBSTMTS=1 option and a Travis Job so this does not happen again.

[cdecker]

This has been in the codebase for quite some time, since 50ff0b2, but is only triggered when we run a plugin that uses the db_write hook. I think it must be that the query gets parsed and executed correctly as long as we use prepared statements where the parser does not combine the ? placeholder with the WHERE that immediately follows it. During the expansion for the plugin we then perform a string replacement where the timestamp gets juxtaposed to the WHERE which is no longer syntactically valid, which then causes any attempt to execute the expanded statement to fail.

Impacted RPC calls (including any plugins that make use of these calls):

• reserveinputs
• fundpsbt if a reservation was specified which is true
• utxopsbt same as fundpsbt
• sendpsbt

So the crash is triggered only if a) we have a db_write hook plugin, b) the plugin crashes while trying to parse/execute the statement and c) call any of the above RPC calls. This is pretty much only the dblog.py plugin.

[m-schmoock]

@cdecker I pulled in your commits from #4092 and fixed the missing generated SQL files for NO_PYTHON of commit 3942e67 that failed job0.

[jsarenik]

utACK 9b02c78

[cdecker]

ACK 9b02c78