[v7r2] Add environment variable to speed up the CS

[chrisburr]

When profiling the production agents/services in LHCb I've notice that a significant amount of time is spent waiting for one of the three locks in the CS. This change can make both single and multithreaded code that heavily uses the CS significantly faster (hard to measure/define but I've seen 2x in single threaded and 4x in multithreaded when testing).

While I can see why the locks are put in place in the CS I think they're actually implemented in such a way that they're not that useful while having a big impact on the overall CS performance.

Additionally, the "dangerZone" locks have been broken for the last 12 years as the disableDangerZones option still decrements the thread count causing the thread count to go negative and never be respected properly (potentially fixed by #5183 but I think it's better just to get rid of the locks):

In [1]: from DIRAC.Core.Base.Script import parseCommandLine
   ...: parseCommandLine()
   ...: from DIRAC.ConfigurationSystem.Client.ConfigurationData import gConfigurationData
   ...: gConfigurationData.runningThreadsNumber
   ...:
Out[1]: -4

As this change obviously has the potential to cause problems, @chaen suggested using an environment variable to allow this to be quickly enabled/disabled in v7r2.

I also add a cache on the value of gConfigurationData.getRefreshTime() as it's accessed at least once for every CS operation.

See also: DIRACGrid/diraccfg#5

BEGINRELEASENOTES

*Configuration
NEW: Add DIRAC_FEWER_CFG_LOCKS environment variable to significantly improve multithreading performance in CS heavy workloads

ENDRELEASENOTES

[fstagni]

Do you know why the docs are failing?

[andresailer]

For the docs test: I think there was a problem with the infrastructure downloading a package, but we can't re-run those PR builds manually

[chrisburr]

Yeah it was hit by the fastly outage earlier this week which brought down half the internet: https://www.fastly.com/blog/summary-of-june-8-outage