fix(BRIDGE-614): read onDiskLiteral in applyMessageUpdated before db transaction

[annatar]

If a panic happens in appy(), it doesn't block potential Wait/WaitContext listeners and applies updates.Done.

Concurrently get/set in a db transaction doesn't contest for the same lock - read the literals before the transaction.

[ElectroNafta]

There's three separate things getting addressed here:

1. The panic recovery
2. Changing when some things get locked / or whether a lock is used
3. Actions related to importing/moving/copying recovered messages

I'd split them off into their own MR's and commits. AFAIK this is the order of importance 2 -> 1 -> 3.

I only took a better look at part 2 thus far, and that one looks good and clear. But I'm not so sure about 3 in particular. Rarely touched, and based off of the evidence we have the deadlock shouldn't be related to that part in particular.

[annatar]

There's three separate things getting addressed here:

1. The panic recovery

2. Changing when some things get locked / or whether a lock is used

3. Actions related to importing/moving/copying recovered messages

I'd split them off into their own MR's and commits. AFAIK this is the order of importance 2 -> 1 -> 3.

I only took a better look at part 2 thus far, and that one looks good and clear. But I'm not so sure about 3 in particular. Rarely touched, and based off of the evidence we have the deadlock shouldn't be related to that part in particular.

I will split them up and open them as separate prs. The importing/moving has the same codepath as 2, so they can be included in one. The panic recovery is its special thing

[annatar]

@ElectroNafta split up the MR into a stack, each containing separate changes