[mtrossbach]

A new CI test for two things that need more than one thread to show up.

The first part sorts and indexes enough rows that the sorter hands work to worker threads (PRAGMA threads=4, temp_store=FILE, cache_size=10). With the default of 100000 rows, the worker threads open 12 of the 14 to 16 temporary files. The test checks that the ORDER BY and the CREATE INDEX finish within 60 seconds, that worker threads opened temporary files at all, and that the files of an encrypted database contain no plaintext. The same run on a plaintext database must show the rows in the temporary files, so the check itself is known to see the sorter's data. A VFS below the Multiple Ciphers VFS does the counting.

The second part calls sqlite3_backup_init with both databases encrypted, both plaintext, and the two mixed cases, which are refused. Afterwards a second thread must be able to take the mutexes of both connections with sqlite3_mutex_try, so a mutex left locked shows up as a failure instead of a hang.

The second thread and the timeout use sqlite3ThreadCreate, so the test needs no platform code beyond getting the thread id.

Testing (macOS arm64, flags from Makefile.am):

• On 329a142 all checks pass, in about 3 seconds; the other CI tests pass as well.
• On 5a9d89f and on v2.6.1 the ORDER BY does not finish, and the test fails after 60 seconds with exit code 1.
• On 0a69702 the four mutex checks for the two refused backups fail; everything else passes.
• Built with ThreadSanitizer it reports only races inside SQLite's own sorter code (the same reports come from plain SQLite); AddressSanitizer and UBSan are clean.