feat: improve type safety when combining unis with limited concurrency

[nikolassv]

As discussed in #1735, this PR adds method overriding of the usingConcurrencyOf(int) to the classes UniAndGroup2 , UniAndGroup3, UniAndGroup4 and similar classes.

Currently, usingConcurrencyOf(int) is implemented only in their common parent class UniAndGroupIterable which return an UniAndGroupIterable object, resulting in a loss of type information.

For example:

public Uni<Integer> sumFromUnis() {
  Uni<String> a = Uni.createFrom().item("1");
  Uni<Integer> b = Uni.createFrom().item(2);
  Uni<Float> c = Uni.createFrom().item(3.141);

  return Uni.combine().all().unis(a, b, c)
    .usingConcurrencyOf(1)
    .with(l -> Integer.parseInt((String) l.get(0)) + (Integer) l.get(1) + Math.round((Float) l.get(2));
}

In this example, we must use .with(List<T1>) of UniAndGroupIterable which lacks specific type information about each uni. As a result, we nee to cast each list element to its expected type, which may easily introduce new errors.

With this PR, the usingConcurrencyOf method in each typed UniAndGroupX class returns the appropriate typed UniAndGroupX instance. This allows the use of the corresponding .with method directly, simplifying the example as follows:

public Uni<Integer> sumFromUnis() {
  Uni<String> a = Uni.createFrom().item("1");
  Uni<Integer> b = Uni.createFrom().item(2);
  Uni<Float> c = Uni.createFrom().item(3.141);

  return Uni.combine().all().unis(a, b, c)
    .usingConcurrencyOf(1)
    .with((x1, x2, x3) -> Integer.parseInt(x1) + x2 + Math.round(x3);
}

This solution maintains the source API without breaking any existing test. However, Revapi flags it as a binary incompatibility issue due to a covariant return type change (see https://revapi.org/revapi-java/0.28.1/differences.html#java.method.returnTypeChangedCovariantly).

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.40%. Comparing base (be44288) to head (f66e00e).
Report is 11 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #1736      +/-   ##
============================================
- Coverage     89.48%   89.40%   -0.09%     
- Complexity     3278     3280       +2     
============================================
  Files           458      458              
  Lines         13349    13365      +16     
  Branches       1651     1651              
============================================
+ Hits          11946    11949       +3     
- Misses          791      794       +3     
- Partials        612      622      +10     

Files with missing lines	Coverage Δ
...n/java/io/smallrye/mutiny/groups/UniAndGroup2.java	62.50% <100.00%> (+3.40%)	⬆️
...n/java/io/smallrye/mutiny/groups/UniAndGroup3.java	61.53% <100.00%> (+3.20%)	⬆️
...n/java/io/smallrye/mutiny/groups/UniAndGroup4.java	60.71% <100.00%> (+3.02%)	⬆️
...n/java/io/smallrye/mutiny/groups/UniAndGroup5.java	59.37% <100.00%> (+2.70%)	⬆️
...n/java/io/smallrye/mutiny/groups/UniAndGroup6.java	58.82% <100.00%> (+2.57%)	⬆️
...n/java/io/smallrye/mutiny/groups/UniAndGroup7.java	58.33% <100.00%> (+2.45%)	⬆️
...n/java/io/smallrye/mutiny/groups/UniAndGroup8.java	57.89% <100.00%> (+2.33%)	⬆️
...n/java/io/smallrye/mutiny/groups/UniAndGroup9.java	57.50% <100.00%> (+2.23%)	⬆️

... and 9 files with indirect coverage changes

[cescoffier]

LGTM, let's wait @jponge

[jponge]

Great work @nikolassv 🙏

I am for introducing this change in 2.7.0 even under semantic versioning rules.