Full trust Wino Server implementation.

[bkaankose]

This PR enables full trust capabilities for UWP application to support capabilities that UWP apps don't allow by delegating all synchronizer actions into separate process called Wino Server.

History
Previously Wino Mail had a background task that runs a full synchronization on all accounts every 15 minutes. This interval can't get any lower due to restrictions on UWP apps. This background task was registered as out of process, meaning that any crash happening wouldn't affect the actual client.

Time showed that background tasks are not stable enough to use for mail synchronization scenario. They have short lifetime and Windows may decide to not to run them at all due to low batterry etc. Also managing everything in a separate background task is hard to manage in the code.

We had 2 separate solution to overcome these problems:

1. Develop a new separate application that'll be packaged with Wino Mail to support all synchronizations.
2. Upgrade to WinUI3 - WinAppSDK application.

Second path is the ideal scenario for the app going forward but this required lots of time and effort for an application like Wino Mail. That's why, I decided to go with the first option. I did not want to make users wait for another big release for months. First option will contribute for upgrading the app to WinAppSDK in the long run anyways.

Benefits of the server

1. Stable background synchronization / request execution.
   Previously everything ran on the client (the actual Wino Mail UWP application) including queueing user actions into synchronizers and actually doing the synchronizations. This meant that once you terminate the application there is no way that any of these actions will continue running in the background. In the new architecture client has no idea about any of the synchronization related code.

2. Unrestricted UWP capabilities

Some of the functionalities that are not available in UWP apps will not be possible with the server. Anything UWP can't do, will be handled by the server. Stuff like:

• Localhost loopback exception for Proton Mail
• Printing files (it's possible but very hard to manage due to complex APIs and WebView2)

can be done on the server. They are not implemented in this PR, for the underlying support is here.

New diagram for queueing user action to the server

flowchart TD
    A[User Actions] -->|Process| B[WinoRequestProcessor]
    B -->|Prepare Package| C[WinoRequestDelegator]
    C -->|Validate Action| D{Is Action Valid?}
    D -->|No| F[Prevent Action]

    subgraph Client
        A
        B
        C
        D
        F
    end

    D -->|Yes| E[Queue Action for Server]
    
    subgraph Server
        E --> G[Account Synchronizer]
        G -->|Batch Actions| H[Batch Queue]
        H -->|Apply UI Changes| I[Delegate UI Updates to Client]
        H -->|Send Batches over Network| J{Network Call Successful?}
        J -->|No| K[Delegate Revert UI Changes to Client]
        J -->|Yes| L[Determine Sync Type - Full or Partial]
        L --> M[Perform Synchronization]
        M -->|Delegate UI Updates| N[UI Updates on Client]
    end

    subgraph Client
        I --> O[UI Update]
        K --> P[Revert UI Update]
        N --> Q[UI Update]
    end

Loading