parallel execution of codesign for better performance

[glyph]

What is the problem or limitation you are having?

Repeatedly code-signing a bundle with a large number of embedded binaries can be quite slow, just because codesign is itself not the fastest. It would be nice to run it in parallel.

Describe the solution you'd like

I think something with multiprocessing is likely best, to avoid taking a dependency. Or you could take a dep on Twisted and use the thing I wrote for Encrust, but that is honestly untested and pretty janky; if you have a preference for that I could clean it up and sign it. (It might work a bit more cleanly ^C and it doesn't use pickle, but there aren't many other reasons to prefer it.)

Describe alternatives you've considered

It could just stay slow, I guess?

Additional context

If the tool is run in parallel and the user doesn't "Always Allow" in the keychain prompt, it can pop up N prompts where N is the level of parallelism. It might be good to grab the signing secret from the keychain before signing, then pass it on the command line or env when invoking the tool, so that only one prompt is issued.

[freakboy3742]

Closing as a duplicate of #1201, which already has a prototype patch (that still needs work, but it's much faster!)