[Libreoffice] Code review for some threadlocking in webdav

[Caolán McNamara]

I'd like to cherry-pick the attached to 3.3

It should fix https://bugzilla.redhat.com/show_bug.cgi?id=661809

This is a long story, but see the backtrace attachment at the above url
there thread 1 and thread 8 both end up mangling libgcrypt which neon is
using. 

https://bugzilla.redhat.com/show_bug.cgi?id=637738 is an earlier one
which is already fixed in 3.3

What happens is that normally neon thread-safely inits libgcrypt and in
most other threaded apps it all works fine. In OOo however we happens to
init cups before we init neon, so cups inits libgcrypt
*non-thread-safely*, and once initted libgcrypt cannot be re-initted to
be thread safe again.

Aha, you say, why not just fix cups to initialize gcrypt thread-safely, 
well, been there, done that.
https://bugzilla.redhat.com/show_bug.cgi?id=544619

Alas if you do, then someone dlopens cups, dlcloses it and libgcrypt
provides no way to be *de*initted correctly, i.e. then this happens.
https://bugzilla.redhat.com/show_bug.cgi?id=559940
https://bugzilla.redhat.com/show_bug.cgi?id=553834
where the locking methods that libgcrypt now relies upon have been
ripped away by the dlclose of cups.

C.