Attempt to reassemble messages produced by the mailbox state debug tool.
Unfortunately, most of it will only work if the messages have been fully
decrypted. To handle encrypted messages we need to have access to the
user's keyring, which is not available.
* Ensure IMAP service sync cancel request waits until the sync has
completely cancelled rather than just signaling. It's possible that
due the context reset on `group.Cancel` that something may have not
have been bookmarked correctly in subsequent sync restarts.
* Handle connection lost/restored events in the services. Removes the
need to lock bridge users. Which could conflict with other ongoing
lock operations. Additionally, it ensure that if one service is
blocked it doesn't block the entire bridge.
* Revise access to bridge user locks.
Ensure periodic user tasks are terminated before the other user
services. The panic triggered due to the fact that the telemetry service
was shutdown before this periodic task.
The IMAP service no longer blocks the event loop from progressing. When
syncing the event loop continues as usual, allow other parts of the
bridge to continue updating.
Once the sync is complete, it resets the event id back to the last
handled id before sync started and then we play catch up.
* Fix wrong context use for message downloads
* Fix delete of sync data failing due ErrNotFound
* Pre-allocate attachment data buffer before download
* Fix calculation of progress if message count is higher than total
Update to latest Gluon to allow access to the database for bridge. The
cache is placed in a `SharedCache` type to ensure that we respect calls
to `Connector.Close`.
In theory, this should never trigger an error, but this way we can catch
it if it happens.
https://github.com/ProtonMail/gluon/pull/391
Add two separate toggles to control event loop pausing. This is required
to prevent cases where the bridge requests the event loop to be paused
but a sync process completes and resumes the event loop.
For the loop to resume now both states need to be set to false. This
will be removed once GODT-2848 is implemented.
Enable the User Event, User Identity and User SMTP service. The services
don't persist any data at the moment to avoid conflict with the existing
event loop.
Rather than accessing the Bridge user list, each user register their
individual SMTP service with the server manager.
Note that some dependencies on the user data are hidden behind the
`UserInterface`. These will be removed in a future patch.
Refactor code to isolate the SMTP functionality in a dedicated SMTP
service for each user as discussed in the Bridge Service Architecture
RFC.
Some shared types have been moved from `user` to `usertypes` so that
they can be shared with Service and User Code.
Finally due to lack of recursive imports, the user data SMTP needs
access to is hidden behind an interface until the User Identity service
is implemented.
Rather than match the web client behavior (removing labels) when
messages are appended to trash, we simply omit the check to see if the
message in trash is present in other labels.
This will produce the same end result and will resolve the issue of
users not being able to fully delete their messages.
Previously we were not filtering out labels we ignored from the
perma-delete check. The introduction of new system label types could
break this check leading to user never being able to perma-delete
messages.
Previous attempt at fixing a bug in the send recorder (GODT-2627)
introduced a new problem where if the same message is sent multiple
times with different recipients it is possible to trigger a case where
the incorrect wait channel is chosen. This in turn led to IMAP client
not recognizing that message has been successfully submitted. This
case is represented by
`TestSendHashed_SameMessageWIthDifferentToListShouldWaitSuccessfullyAfterSend`
but could potentially happen over time or due some other
concurrency/scheduling wake up order.
To prevent this from happening every send recorder request now requires
that the full list of addresses be presented. This is necessary for us
to locate the correct entry and its respective wait channel.
Finally each unique send recorder request is assigned an ID, in order
to ensure make sure that if we ever need to cancel a request,
we don't accidentally cancel a similar request if the original was
removed from scope due to expiration.
