After we detect that the user has suffered the GODT-3003 bug due the
vault corruption not ensuring that a previous sync state would be
erased, we patch the gluon db directly and then reset the sync state.
After the account is added, the sync is automatically triggered and the
account state fixes itself.
Update ServerManager to follow the new expected behavior. The servers
will only be started when one user is active.
If all users are logged out or removed from the system, the servers will
stop.
If the network goes down, the servers will stop and resume once network
has been restored.
Add a dedicated go-routine whose sole responsibility is to manage the
life time of the IMAP and SMTP servers and their listeners.
The current implementation behaves the same way as the previous state.
The new behavior will be implemented in a follow MR.
Update UIDValidity to be timestamp with the number of seconds since
the 1st of February 2023. This avoids the problem where we lose the
last UIDValidity value due to the vault being missing/corrupted/deleted.
It's currently impossible to wait until all SQLite write finish to disk.
This is not guaranteed when closing the ent DB client.
The existing code to move the cache handles the case where the
new location is on a new drive. However, due to the above issue this can
now lead to database corruption.
To avoid database corruption we now use the `os.Rename` function and
prevent moving the cache between drives until a better solution can be
implemented.
Deleting the file isn't enough because it's still held in memory
and is written back to disk on the next write (SetLastVersion during
bridge teardown).
It's possible (but very rare, I don't think proton still allows it)
for an address to have no keys. If we try to load the address keyring
for such an address, this change logs a warning that no decryption
entities were found in the unlocked keyring.
It bumps liteapi to a version that does not return an error when no
keys could be unlocked.
Depending on the timing of bridge closure, it was possible for the
IMAP/SMTP servers to not have started serving yet. By grouping this in
a cancelable goroutine group (*xsync.Group), we mitigate this issue.
Further, depending on internet disconnection timing during user login,
it was possible for a user to be improperly logged in. This change
fixes this and adds test coverage for it.
Lastly, depending on timing, certain background tasks (updates check,
connectivity ping) could be improperly started or closed. This change
groups them in the *xsync.Group as well to be closed properly.
