Properly notify gpgme about spawn executable location on Windows

[Kaganski Mike]

Hi Thorsten, *,

When working on a 6-0-based branch on Windows, in make check, two python 
tests emit modal error dialogs about missing gpgme-w32spawn.exe:

> ---------------------------
> GpgME not installed correctly
> ---------------------------
> gpgme-w32spawn.exe was not found in the detected installation directory 
> of GpgME
> 	"C:\lo\src\core\instdir\program\python-core-3.5.5\bin"
> 
> Crypto operations will not work.
> 
> If you see this it indicates a problem with your installation.
> Please report the problem to your distributor of GpgME.
> 
> Developer's Note: The install dir can be manually set with: 
> gpgme_set_global_flag
> ---------------------------
> ОК
> ---------------------------

For completeness, the tests are sw_python and 
pyuno_pytests_insertremovecells, but this is not really important; 
obviously, the tests themselves don't need the initialization of 
security context, and the unneeded initialization was fixed somewhere 
down the road, and later versions don't block on the tests.

However, I suppose that it's possible in theory that some user python 
script could ultimately need initializing gpgme. In that case, the 
problem would hit the user. Having a modal dialog waiting on a possibly 
headless server is not a correct behavior :-)

The cause here is that by default, gpgme only expects to find the spawn 
process in the same location as the current executable (see 
_gpgme_get_w32spawn_path and _gpgme_get_inst_dir in 
gpgmepp/src/w32-util.c). It works when the executable is soffice.bin; 
but for python, which is located in a subdirectory of instdir/program, 
this is not true (see error message above). It needs to be told 
explicitly where to look for the executable; and it's only possible 
using gpgme_set_global_flag call.

So I went ahead and prepared a patch for this: 
https://gerrit.libreoffice.org/71014, which adds a check if the spawn 
executable is in the same directory as current process executable, and 
if not, queries UNO_PATH environment variable to check if it contains 
the executable, to notify gpgme about the path.

My questions are:

1. First of all - do I understand it correctly that the problem is real 
- so there are possible scenarios involving e.g. python (or another 
process which executable is not in LO's instdir/program), that might 
need gpgme? I'm not familiar with our scripting framework, so I might 
actually invent a non-existing problem after all. I see that problem 
happening only with those tests, and I don't know if the later fix has 
completely ruled away the possibility to run that code from python, or 
just made that called only when really needed (which implies that it 
will happen eventually).

2. To find the executable, I use UNO_PATH envvar. As far as I can tell, 
even directly running soffice.bin without having UNO_PATH set in 
environment, sets the variable correctly, so this works as expected. But 
is there a better way?

3. The patch needs to add a gpgmepp wrapper for gpgme_set_global_flag 
function, because the function itself is not accessible from the place: 
if I simply used it, linking it fails:

> [LNK] Library/xsec_xmlsec.dll
>    Creating library C:/lo/src/core/workdir/LinkTarget/Library/ixsec_xmlsec.lib and object C:/lo/src/core/workdir/LinkTarget/Library/ixsec_xmlsec.exp
> SecurityEnvironment.o : error LNK2019: unresolved external symbol gpgme_set_global_flag referenced in function "public: __cdecl SecurityEnvironmentGpg::SecurityEnvironmentGpg(void)" (??0SecurityEnvironmentGpg@@QEAA at XZ)
> C:/lo/src/core/instdir/program/xsec_xmlsec.dll : fatal error LNK1120: 1 unresolved externals

I could overlook how to use the function without the need of the wrapper 
- if so, please give me a hint how to do that properly. If there's no 
way to do that, then I'll create a pr to https://github.com/KDE/gpgmepp.

Thanks.

-- 
Best regards,
Mike Kaganski