[deliver] Implement parallel screenshot downloads

[CognitiveDisson]

Checklist

• I've run bundle exec rspec from the root directory to see all new and existing tests pass
• I've followed the fastlane code style and run bundle exec rubocop -a to ensure the code style is valid
• I've read the Contribution Guidelines
• I've updated the documentation if necessary.

Motivation and Context

I am working on an application that supports many languages. Therefore, loading and unloading screenshots for all of them takes a lot of time. To get started, I would like to add a parallel download of screenshots. I know that Fastlane is not designed for parallel operations, but in this case I think this is a suitable solution.

Description

I added the creation of a thread for downloading screenshots for each language, this should be the optimal solution (the optimal number of threads and file descriptors) and should not create collisions.

Testing Steps

Execute fastlane deliver download_screenshots on the current release version of Fastlane and on version from the current branch.

Averaged local measurement results:
Hardware: MacBook Pro (15-inch, 2019) 2.4 GHz Intel Core i9 32 GB 2400 MHz DDR4
Input: 31 language * 4 devices * 9 screenshots = 1116 images 421.6 MB
Connection: WiFi 46.9 Mbps

Result before: ~ 375s
Result after: ~ 99s

[googlebot]

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

[janpio]

Wow, this changes the game quite a lot.

Are you sure this would not have any possible negative effects? Is it safe to just spawn that many threads (for some apps this will be quite a lot, right?)

[CognitiveDisson]

Hi @janpio!

Are you sure this would not have any possible negative effects?

The only negative effect that I see is that the processor and network channel will be more busy. The processor will be more loaded. And network failures with a weak connection are slightly more likely.

Also on a single-core processor, this will slightly slow down the download due to additional resources for creating threads.
But I think that these are insignificant minuses, since I think that now a small patch of developers uses a single-core processor and dialup Internet 😅

The number of images in the store, the size of the images, and the number of languages supported are limited. Apple supports 40 localizations, 10 screenshots per device, 4 types of devices, 1600 images in total.

On a multi-core processor, creating threads, even if there are more threads than cores, will not lead to negative overhead. I create threads according to the number of localizations, maximum 40, this is not a lot. So it should be fine

[joshdholtz]

@CognitiveDisson @janpio This is going to conflict with changes I have going on in the 2.150.0 branch. Can we make this an issue to implement later? 😇

[joshdholtz]

@CognitiveDisson There are some conflicting changes now due to the recent App Store Connect API updates. Do you mind rebasing and fixing this? 😇

[CognitiveDisson]

@joshdholtz Of course, I will do it soon. Thanks for letting me know.

[CognitiveDisson]

@joshdholtz Done and checked

[joshdholtz]

This is so quick! Thanks for rebasing this 😊 Really appreciate it! ❤️

[fastlane-bot]

Hey @CognitiveDisson 👋

Thank you for your contribution to fastlane and congrats on getting this pull request merged 🎉
The code change now lives in the master branch, however it wasn't released to RubyGems yet.
We usually ship about once a week, and your PR will be included in the next one.

Please let us know if this change requires an immediate release by adding a comment here 👍
We'll notify you once we shipped a new release with your changes 🚀

[fastlane-bot]

Congratulations! 🎉 This was released as part of fastlane 2.151.2 🚀