Downgrade global write lock after upgrading format

[dra27]

Tentative fix for #4597 - is it strictly necessary to retain the lock at all after loading the global config?

This definitely needs a shiny new reftest - "all" that's required is a dummy package which calls opam var prefix as part of its build and to create a switch with that package.

[AltGr]

Test should be fairly easy to add, see the short documentation and examples in legacy-local.git.

I may actually be in favor of completely reverting #4314 for now... if I know one thing about locks it's that their flow must really be kept as straight-forward as possible. I was already uncomfortable with adding with_flock_upgrade (you need to be really sure that you can't possibly hold a lock someone else might be waiting on before calling that, or at least that they can't be concerned with what you are upgrading... but since these things are all over the place...)
So the fix is probably correct, but it seems too complex to me to be really sure...

[rjbou]

Looking at #4314, there was already a write lock upgrade, but it was located in the upgrade function. With the new on the fly mechanism, it is no more needed to always take a write lock. This temporary write upgrade lock can be reintroduced temporarily in OpamFormatUpgrade.as_necessary.

[rjbou]

In fact, it shouldn't be needed to release the lock, as global_lock is only used with OpamFilename.with_flock_upgrade f that restores previous lock level after f. In previous version, it was restored to a write lock, so it should be more blocking. I need to take a closer look at these mechanism. Lock upgrading/downgrading is really touchy!

[rjbou]

Superseded by #4612.
Thanks!