self.encoding which we set in the init is only intended
to decode gpg´s stderr which uses a system specific encoding.
if we dont encode the data we pass to python-gnupg ourself, it will fallback and use self.encoding.
This might be of no concern if self.encoding is set to 'utf8' and when we are on Linux
which has a preferred encoding of 'utf8'.
But if we are on Windows the preferred encoding for stderr
is most of the time not 'utf8'. If python-gnupg tries to decode a stderr stream that is for example
encoded with 'cp1252' with our set encoding of 'utf8' this will fail.
The solution is to pre-encode the data before we pass it to python-gnupg, so it does not have to
use self.encoding as a fallback. And set self.encoding='latin1' because latin1 will not yield exceptions
on decoding errors. Also gpg itself will fallback to latin1 as stderr encoding when it cant determine the
preferred encoding of a system.
self.decode_errors is used for something differently, and has no influence on the situation.
Fixes#8644
python-gnupg uses latin1 as default encoding because GPG itself uses
latin1 as default.
We should not override this default with getpreferredencoding, because
getpreferredencoding maybe returns something else than what GPG is configured
on that system.
Example: On Windows
GPG is run in default mode with 'latin1'
getpreferredencoding returns 'cp1252'
The approach would be now to default to latin1 as it is GPGs default.
And if the User sets a different ecoding for GPG he has to set it in
Gajim aswell.