when max_threads=1, do not create a thread pool

[alaniwi]

@glevava

As you know from our discussions on Slack, I found that during checksum calculation in esgprep drs, there were some threads deadlock problems. I understand that you are implementing use of hashlib for the checksums in place of running sha256sum via os.Popen, and hopefully this will be thread-safe. However, I have not succeeded in setting up a reliable test environment to be sure that it will solve all the problems, and I do not want some unpleasant surprise during CMIP6 operations.

I tried to investigate solving this by using processes in place of threads (that is, using multiprocessing in place of multiprocessing.dummy), but this would require the input to be able to be pickled, which seems very difficult to achieve, given the complexity of the ProcessingContext object.

So now I propose a simple "safety valve", just in case of any problems. Simply, if --max-threads is set to 1, then it will not create any pool, but it will instead use the simple itertools.imap for the processing, so then we can have good confidence that there will be no problems with interactions with the threading library (it will still be imported, but not used). It will be reassuring to have this option available, even if in the end we do not need it. In fact if it arises during operations that we need to set --max-threads=1, then we can easily compensate for the slower run time by processing more datasets simultaneously in the calling script.

I have tested drs and mapfile functions to check that the result with --max-threads=1 is still the same as with more threads, and it seems to be (apart from possibly the ordering of the commands in drs or the order of the lines in the mapfiles).