Make Fetcher pipelien faster

[wkelly17]

adjust fetcher pipeline to reduce glob overhead, and use a thread pool for IO ops

Please include a summary of your changes.

1. Small change - I replace the -t (trace) argument with -l (log level that matches to standard py log levels.). The current debug or warning wasn't granular enough. Debug spits out too much, so I added some higher level logs under info and made that the default.
2. At the start of each loop -> We're just gonna call one rglob(*). There were already multiple call for *.wav, and several for nested mp3 that was likely causing pretty significant overhead. I wasn't completely sure whether the workers had any interdependence or not (i.e. the files created by one worker affected another). I tried to refactor on the "safe side" by assumin so. To avoid having to looks for new files with an rglob, the mutable set of all_files is passes around. When I worker finihses, it updates the set by union and by exclusion based on what it has created or deleted. I did some ad hoc testing, and I don't think we're at the scale where reading into memory matters too much yet. I testing rglob on my own comptuer from home directory and read 2.5 million files before it started to churn. You can also fit about 50 million paths into a set in about 1.5 mins on my machine, and then that's only about 2gb of memory (sort I think it should be fine to just read the whole generator into memory based on those ad hoc tests).
3. Since I made the assumption the workers might be interdependent (I just couldn't tell looking only at the code level), I decided to parallelize the work in each worker. I think the majority of the input is most likely IO, which makes it a pretty good case for green threads based on some stuff Craig sent me, so basically each worker was refactored to internally leverage a thread pool.
4. I adjusted the base docker image for the build to python 3.12 since ther was an bug report for prior to 3.12 with regards to some rglob internals causing significant slowdowns (see Path.rglob performance issues in deeply nested directories compared to glob.glob(recursive=True) python/cpython#102613). And then it bumped the node base version since they are bundled together, but node 14 is definitely EOL so it probably needed bumping too.

Some of this stuff was fairly new to me, so it may not be the most pythonic, and it may not even quite be correct, but I figured it was a good first stab of the two things that almost certainly are the where the largest amount of time is being spent.

Please feel free to review and revise. I would have tested it more, but I don't have a local directory that matches what the workers are looking for mocked, and I don't have ssh access to run it against the dev cdn or anything of that nature.

I'm sure there is room for improvement, but I think that'd require some changes I can't control (i.e. hashes vs timestamps) and a more thoughtful rearchitecting.

---

This change is 

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[danparisd]

LGTM

The base branch was changed.