When doing a crypto operation with GpgOL (e.g. decrypting / encrypting) the
Outlook UI is blocked until the crypto operation in the UI Server is completed.
This can be quite a long time as the user may has to enter the passphrase or
select recipients.

Clicking into Outlook for example while Outlook is blocked causes windows to
treat Outlook as "unresponsive" Window offering to kill it eventually.

While it is a technical limitation that MAPI and Outlook Object Model Objects
can only be accessed by the Main Thread of Outlook I'm saying that this is a
bug. Although it has always been that way. (At least when using Kleopatra)

• Users see the "Unresponsive" Window and Report that Outlook has crashed.
• When Windows kills outlook because it is unresponsive Outlook deactivates

GpgOL because it caused it to crash.

While the actual crypto stuff already happens in another thread the thread is
joined in engine-assuan's engine_wait. So we basically turn it into a blocking call.

While Werner mentioned that he might have solved this in previous versions I'm
not seeing this in the code. I'll have to test with GPA as it might be that
progress information causes gpgol to temporarily yield the event loop.

My approach to solve this would be to collect all information we need from the
OOM / MAPI in a context object that includes a reference to the Mailitem object
we work on. Do the crypto in another thread and then return to the Main Outlook
thread through a Windowmessage (as already done in windowmessages.cpp).

We then have to access the mailitem again and update / set the encrypted or
decrypted data structures accordingly. Keeping track of the validity of the
mailitem pointer can be done through the event sink objects enable us to be
notified once a mailitem pointer is invalid.

There can be other problems though. E.g. I've already noticed that if you
trigger a send event at the wrong time Outlook 2016 just crashes. (Without
blaming gpgOL for this). This is Bad because for sending we would have to do
something like this:

-> Cancel Send event and call save instead.
-> In the AfterWrite of the Save event -> do crypto job
-> After crypto is done update the mailitem data structure
-> Call send again and don't cancel it.

In my tests this last call tended to crash for reasons unkown.