It should not be possible to reach this state on purpose. But due to
scheduling and synchronization variances, it is possible in theory that
a UserDeathEvent can occur at the same time as the bridge is closing,
causing a call to `User.Close()` to be executed 2 times.
To avoid this in the future we just clear the map after all the channels
have been closed.
Rewrite the vault to have one RWlock rather then two separate locks for
data and reference counts.
In certain circumstance, it could be possible that that different
requests could end up in undefined states if a user got deleted
successfully while at he same time another goroutine/thread is loading
the given user.
While I have not been able to reproduce this in a test, restricting the
access scope to one lock rather than two, should avoid corner cases
where logic code is executing outside of the lock scope.
* Remove distinction between values with and without reply.
* Hide types that don't need to be public.
* Don't allow direct access to the request's internal types.
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.
The sync process was getting stuck since we never handled the case where
the update to Gluon failed. This caused the flush stage to exist, but
the sync process would continue until it eventually gets stuck due to
lack of progress.
Changes to GPA 503 handling is now causing GPA client to treat this as
context cancelled rather than producing 503. To be re-enabled as part of
GODT-2527.
It is possible, on slower machines, that the new event poll task is not
yet registered and attempts to cancel have nothing to cancel.
In this case, we need the refresh event to cancel the task, at that
point it is guaranteed that the task exists.
