`Cancel` UI should have well-defined semantics.
Let us consider a scenario of decryption (with multiple methods).
Current situation:
- gpg supports cancelling one method. Canceled -> it tries another method.
- gpgme considers that single `GPG_ERR_CANCELED` means cancelling the whole process of decryption.
- pinentry-tty and pinentry-curses support `GPG_ERR_FULLY_CANCELED` by `Ctrl-C`. But other pinentry implementations have no support (only `GPG_ERR_CANCELED`).
We could have clear definition like:
- `GPG_ERR_CANCELED` means cancelling one method
- `GPG_ERR_FULLY_CANCELED` means cancelling all (cancelling the whole process of decryption)
- meaning of empty input depends on the context (for symmetric encryption, meaning "skip", for example)
If this definition is OK, then we will do:
- Enhance other pinentry implementations to raise `GPG_ERR_FULLY_CANCELED` (for example, offering another button or new semantics of closing the dialog forcibly).
- Modify gpgme state-machine
- not raise an error by a single `GPG_ERR_CANCELED`, just record it.
- raise an error by `GPG_ERR_FULLY_CANCELED`
- at the `EOF`, recorded `GPG_ERR_CANCELED` raise an error
- observing new pinentry invocation, clears the cancel record
- Modify gpg
- When pinentry returns `GPG_ERR_FULLY_CANCELED`, cancel all methods