Describe the bug
Changes still exist in the briefcase after calling TxnManager.deleteAllTxns,

To Reproduce
Steps to reproduce the behavior:

1. Open an iModel
2. Make some changes
3. Discard changes by calling deleteAllTxns
4. Restart the application (Not required, but it makes sure it's not just an in-memory caching issue)
5. Open the iModel

You will see all changes that were made in step 2 before discarding.
Recording from Alex

Expected behavior
I would expect that all the changes that were done in step 2 would be reverted in the briefcase. I would not expect the elements to still be present in the viewer.

Desktop (please complete the applicable information):

• Electron-Windows
• iTwin.js Version 5.0.0-dev.116

Additional context
If you make more changes after the discard and push, only the Txns made after the discard will be pushed. This piece of it is desired behavior.

I haven't investigated, but I think the current implementation could lead to data corruption if you edit an element after the discard that was edited in a conflicting way before the discard.

For example, if I

1. create two manholes
2. call deleteAllTxns
3. create a pipe connecting the manholes

Then I would expect the pipe will have relationships pointing to element ids of manholes that don't exist in the cloud iModel.

My uninformed theory
My best hypothesis is that there is some Txn table in the sqlite db that contains the incremental changesets, but it's separate from the "squashed" source data. And the deleteAllTxns function is deleting the records in the Txn table, but not undoing the changes in the squashed data.

@pmconne @alexdunae