Job Launchpad may need a protection against LFN sandbox

We had a case where

1. A user used the DIRAC JobLaunchpad WebApp specifying a LFN
2. The "LFN" specified was not a file, but a directory
3. The job started downloading files under the directory, filling up the WN disk
4. The site found the problem and closed the WN, then contacted us

JobLaunchpadHandler simply adds the specified LFNs to JDL
https://github.com/DIRACGrid/WebAppDIRAC/blob/9948d0ef327368ed1e502f41e029f91de3af121d/src/WebAppDIRAC/WebApp/handler/JobLaunchpadHandler.py#L201

JobWrapper simply passes the sandbox files with "LFN:" to DMS getFile
https://github.com/DIRACGrid/DIRAC/blob/fdfd3a4802a5543369d307cbbb3c0781f2f14219/src/DIRAC/WorkloadManagementSystem/JobWrapper/JobWrapper.py#L1127

Can there be some kind of protection to avoid this?
Preferably in JobLaunchpad, with the number of files, or with the total volume?
If that is difficult in the WebApp, then in JobWrapper where it can tell the disk space and the volume of the sandbox?

Leggi JobLaunchpadHandler.py intorno alla riga 201 e JobWrapper.py intorno alla riga 1127 per tracciare come gli LFN diventano download nella sandbox. Confronta dove potrebbero essere controllati il numero di file, il volume o lo spazio su disco disponibile. Il lavoro è completato quando un LFN di directory non può riempire il disco di un worker node senza essere rifiutato o limitato da una protezione esplicita.

Scritto dal modello di indicizzazione a partire dal testo della issue.