re-visit simplifying the change queue implementation

[samuelstroschein]

Context

The change queue could be implemented without a file_internal table.

Uncertainty exists if the change queue implementation in https://github.com/opral/monorepo/pull/3061 is the "simplest/best" way to go.

• https://github.com/opral/monorepo/pull/3061#pullrequestreview-2238335973
• https://discord.com/channels/897438559458430986/1267939224041291776/1267961744718958717

Proposal

Decide if the change queue should be implemented with a file_internal table or by storing both old and new file values in the queue itself.

[samuelstroschein]

The file_internal implementations leads to bugs. An argument to go with a copy old, new file data implementation.

The code below has two problems:

1. I forgot to use settled, expecting that file writes which happen in resolveConflict are immediately written "to disk".
2. Even using settled didn't work.

The fix was to write to the file table instead of file_internal. Point being, the ergonomics around

[samuelstroschein]

Just ran into another problem with file_internal:

SQLite3Error: SQLITE_ERROR: sqlite3 result code 1: cannot UPSERT a view. 

If i am not mistaken, the current queue implementation will prevent upserts. No matter how we design the public API for files. The two options of 1) writing to a file view that triggers the queue, or 2) writing to "the actual table" and bypassing the queue will always lead to a "I want to upsert but don't bypass the queue" problems.

[samuelstroschein]

The flaky tests with 'driver destroyed" are coming from the current change queue implementation https://github.com/opral/monorepo/pull/3093/commits/75fe4be582f839485b2b4f75b05dd617d561f222.