ci(pre-commit): Prevent cache time-of-use/time-of-check problems

[Holzhaus]

Interally, proselint uses caching to speed up analysis, and the
corresponding code is written in a way that makes it obvious that it is
not intended to run multiple instances of proselint simulatenously.

For example, the memoize function in tools.py suffers from
time-of-use vs. time-of-check problems:

if not os.path.isdir(cache_dirname):
    # ...
    # While this is running, another process may create the
    # `cache_dirname` directory.
    # ...
    os.makedirs(cache_dirname)  # <-- Crashes if `cache_dirname` exists

As the code between the check and the directory creating is quite short
and does not take a lot of time to execute, it's unlikely to encounter
this issue on a reasonably modern desktop computer, but I ran into this
issue multiple times when running proselint via pre-commit on a
relatively slow low-powered ARM device in a fresh docker container.

It would be preferable to rewrite the caching code with multiprocessing
in mind and by incorporating concepts like "Easier To Ask for Forgiveness, not
Permission" [1], but for now, it should suffice to disable
parallel execution in pre-commit.

[Nytelife26]

Sorry, I've only just seen this. Thank you for your contribution!
I'm not so sure about the idea of outright disabling parallelism in pre-commit hooks. I think I'd rather refactor to fix the issue, perhaps by adding a try-except.

[Holzhaus]

I'm not so sure about the idea of outright disabling parallelism in pre-commit hooks.

It's certainly not ideal, but currently proselint is broken on slow computers and will fail intermittently.The parallelism doesn't really make a noticeable performance difference so I thought this was a reasonable workaround until someone finds the time to fix the root cause.

I think I'd rather refactor to fix the issue, perhaps by adding a try-except.

These time-of-check/time-of-use issues are found in many locations in the code base, not just that one code snippet it posted above. And even that one is simplified (I stripped out the legacy cache migration). If you think this is straightforward to fix, than it makes sense to do that. But I wasn't even sure that writing to and reading from the cache is thread-safe when the code that checks if the cache exists isn't. And I currently don't have enough spare time to rewrite proselint's caching logic in a thread-safe manner.