[MRESOLVER-32] Parallel deploy and more

[cstamas]

General improvements regarding threads and thread pool use in code, leaving all the functionality untouched (same things are done, just centralized), while basic connector is the only modified one, that is now able to perform parallel upload as well.

Changes:

• introduced ThreadUtils that supports "core count" expressions (blatantly copied from Maven -T parsing)
• all thread using components redirected to ThreadUtils, removed scattered boiler plate and duplications
• BF collector enhanced: now skipper and parallelCollector are both closeable, ensuring there is no thread pool left dangling
• connector new feature (disabled by default): perform PUTs in parallel

---

In action: https://asciinema.org/a/fBTcOTSJF0cRmHsr8hZuIQrpw
(note: local repo contained m-deploy-p 3.1.0-SNAPSHOT installed, needed to fully utilize deployAtEnd apache/maven-deploy-plugin#38)

---

https://issues.apache.org/jira/browse/MRESOLVER-32

[michael-o]

Please move the introduction of ThreadsUtils to a separate PR. Also the change from int to String might lead to missed input stream the config utils request an int, no?

[slawekjaranowski]

We should provide separate PR with separate issue for each new feature.
As you mention in description I see new features or improvements like:

• dynamic core count
• BF collector enhanced
• PUTs in parallel

[cstamas]

Ok, will do it, but sequentially, as I don't see how to create these 3 PRs simultaneously without conflicts against each other, and I would not like to spend time on fixing conflicts after each merge, just for "purity". So, please then, be prepared for snappy reviews 😉

In other words, having these 3 commits separate is okay, but will not allow their initial purpose (for example to roll back one of them) as all 3 are quite interleaving with each other.

[michael-o]

Ok, will do it, but sequentially, as I don't see how to create these 3 PRs simultaneously without conflicts against each other, and I would not like to spend time on fixing conflicts after each merge, just for "purity". So, please then, be prepared for snappy reviews 😉

In other words, having these 3 commits separate is okay, but will not allow their initial purpose (for example to roll back one of them) as all 3 are quite interleaving with each other.

Layered, sequentically, of course. Not in parallel.

[michael-o]

Why make parallel put an option? I mean if we do parallel downloads by default, why not do the same with uploads? Do you see a risk here?

[cstamas]

Closing this one out, this PR was split in 3:

• [MRESOLVER-317] Improvements for BF collector #238
• [MRESOLVER-318] Cleanup redundant code and centralize executor handling #239
• [MRESOLVER-319] Parallel Deploy Support #240