Install files in parallel

[Thomas1664]

My profiling showed that this PR makes install_files_and_write_listfile() 2x faster (tested with catch2 (39.8/ 24.5 ms) & aws-c-common (21.7/ 11.9 ms) on M2 MacBook Air). However, previous tests on Windows indicated even higher speedups (>= 4x).

Previous behavior

For each installed file individuall, the file type was btained and checked and the file was copied to the installed folder. At the same time, the file path was added to a vector containing a list of all installed files.

The listfile was created using fs.write_lines(). fs.write_lines() results in one write() and one put() (for \n) for each line.

Current behavior

1. Obtain and check the file type of all installed files (parallelized)
2. Create all required directories (not parallelized to avoid race conditions)
3. Copy all files in parallel
4. Write listfile in one go using fs.write_contents_and_dirs().

[Thomas1664]

There's no difference for regular files between remove_all and remove (provided that vcpkg's implementation is identical to the STL): https://en.cppreference.com/w/cpp/filesystem/remove

[Thomas1664]

@BillyONeal Unit tests on OSX failed here. It seems to work again but I can consistently reproduce the failure on my local machine: The test case captures-output fails with error: calling CreateProcessW failed with 2 (unknown error). I'm not sure if this is the same test that failed in CI. I can confirm that this is most likely not caused by changes in this PR because the changed code inside commands.install.cpp is never hit.

[autoantwort]

Btw you can build the format target locally to format all code.

[BillyONeal]

Sorry!

[Thomas1664]

I'm in general happy with attempts to parallelize things but overall I think you need to be much more explicit in proving that everything you call in a parallel context is actually safe to do. Given that the first run of e2e tests experienced a failure and I found races in a cursory review makes me fear that unknown races remain without such a proof.

I think the main issue with parallelizing here is printing. Basically, whenever the program can print anything, needs to be guarded by a mutex which is IMO not possible from the outside. Therefore, we need to make printing inherently thread safe.

[Thomas1664]

@BillyONeal I addressed your concerns regarding conflicting directory creations and interleaved terminal output. I changed the code to write the list file from the main thread and I use a mutex to protect terminal output.