wallet: Add tracing for sqlite statements #27801

I found sqlite tracing was useful for debugging a test in #27790, and thought it might be helpful in other contexts too, so this PR adds an option to enable it. Tracing is still disabled by default and only shown with -debug=walletdb -loglevel=walletdb:trace options.

<!--e57a25ab6845829454e8d69fc972939a-->

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

<!--021abf342d371248e50ceaed478a90ca-->

Reviews

See the guideline for information on the review process.

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

Concept ACK

ACK f45e066 I tested by switching to this commit and doing the following

make -j"$(($(nproc)+1))"
./src/bitcoind -regtest -debug=walletdb -loglevel=walletdb:trace

In different window

./src/bitcoin-cli -regtest  createwallet "node2"

Then you can observe the bitcoind logs example of one

2023-06-01T21:14:59Z [/Users/<my path>/wallet.dat] SQLite Statement: INSERT or REPLACE into main values(x'05666c616773', x'0000000004000000')

tACK f45e0669dd1f1bdb243e645691e44993905a3919

Tested on OpenBSD 7.3, sqlite 3.41.0. Started bitcoind with debug=walletdb -loglevel=walletdb:trace, ran RPCs createwallet, getnewaddress and setlabel and observed the debug output emiting sqlite statements (SQLite Statement: INSERT or REPLACE into main values(.....).

Turning this on will log private keys as they are being written to the db, which seems a little scary.

Turning this on will log private keys as they are being written to the db, which seems a little scary.

Yes when the tracing was turned on, having access to the debug log file would be like having access to the database file. The keys would at least be encrypted if the wallet had a password set, but it could still be scary/unexpected behavior.

I looked into ways of trying to mask values in the sql statement, but the sqlite3_stmt object is pretty opaque and I couldn't find any function https://www.sqlite.org/c3ref/stmt.html that would allow retrieving bound parameters or temporarily rebinding the statement with masked values before expanding it.

So for now I just updated the PR to avoid expanding any update statement that could contain sensitive values. We might be able to do something better in the future like add a more sensitive tracing level, or expand sql statements more intelligently, but the update should be a safe enough compromise that avoids leaking information while still making it easy to see full values by modifying the code.

Updated f45e0669dd1f1bdb243e645691e44993905a3919 -> ff9d961bf38b24f8f931dcf66799cbc468e473df (pr/sqtrace.1 -> pr/sqtrace.2, compare) to avoid expanding sensitive sql statements

ACK ff9d961bf38b24f8f931dcf66799cbc468e473df

ACK https://github.com/bitcoin/bitcoin/commit/ff9d961bf38b24f8f931dcf66799cbc468e473df

ACK ff9d961bf38b24f8f931dcf66799cbc468e473df