Refactor pileup data location in global workqueue to support partial availability

[todor-ivanov]

Impact of the new feature
Global WorkQueue

Is your feature request related to a problem? Please describe.
This feature needs to be deployed with: #11732

Complimentary to allowing partial data placement for Premixed pileup datasets, we need to allow also partial data location in Global WorkQueue. Meaning that we no longer have a hard requirement stating that the pileup container needs to be fully locked and available by wmcore_pileup account, hence data lookup granularity has to change from container to Rucio dataset level.

Describe the solution you'd like
The pileup data location algorithm needs to be refactored to resolve data location based on Rucio datasets instead of the container. Given that some pileup containers have 10s of thousands of Rucio datasets, this algorithm needs to be refactored to allow high concurrency, either relying on the existing pycurl_manager module; or by adopting python asyncio library.

We can likely have a relaxed error handling logic, such as:

• if 100% of the data look-up requests fail, we raise a hard exception and fail the workflow acquisition (to be retried in the next cycle)
• if only a fraction of the data look-up requests fail, we assume those rucio datasets as having an empty location

For Global WorkQueue purposes, if there is at least 1 rucio dataset available in a given RSE (under wmcore_pileup), then we should consider that RSE as a valid pileup location. I do not think it matters for the service to find 100k rucio datasets or only 1 available under a given RSE, as we will simply trust that pileup availability is meeting CompOps criteria.

Describe alternatives you've considered
Note the comment about concurrent library to be used.

Additional context
This is part of the meta issue: #11537

[amaltaro]

Please refer to this comment #11732 (comment), which suggests to couple pileup data location to the MSPileup information, across WM.