use delegating shard tasks for connectedCheck

[RBusarow]

These shard tasks collectively depend upon all Android connectedCheck tasks in the entire project.

Each shard depends upon the connectedCheck tasks of some subset of Android projects. Projects are assigned to a shard by counting the number of @Test annotations within their androidTest directory, then associating those projects to a shard in a round-robin fashion.

These shards are invoked in CI using a matrix. If the number of shards changes, the connectedCheckShardMatrixYamlUpdate task can automatically update the workflow file so that they're all invoked.

The shard tasks are invoked as:

# roughly 1/3 of the tests
./gradlew connectedCheckShard1
# the second third
./gradlew connectedCheckShard2
# the last third
./gradlew connectedCheckShard3

The task filtering we currently use in CI (./gradlew fooShard1 -x :my-project:foo) will still work here, however the "cost" of the excluded task's tests is still accounted for when the sharding is performed.

[rjrjr]

If we have an off by one error and some boundary tests fall between the cracks, how will we notice that shard1 + shard2 + shard3 < allShards? Wondering if there's an invariant check we can put somewhere. 🤔

[rjrjr]

Maybe extract a core of this routine so that you can unit test it?

[RBusarow]

I didn't (and still don't) want to introduce unit tests to build-logic, since the tasks for an included build are not hooked into Gradle's implicit task delegation by default.

For example, if we invoke ./gradlew test today, it'll invoke all unit tests in kotlin-jvm modules. We just expect that to work. But that hook (implicit task delegation) only applies to sub-projects. The build-logic build is not affected by this, so its test task would never be invoked.

We can manually stitch things together, such as with this in the root build.gradle.kts:

tasks.named("test") {
  dependsOn(gradle.includedBuild("build-logic").task(":test"))
}

...but if anything were to happen to that, then the sharding could break in the way you described and no one would be the wiser.

So, instead I refactored it to be as off-by-one-proof as I could. As the tasks are configuring, they assert that the shard allocations total up to the exact number of Android projects and there are no duplicates. So they test themselves every time they're used.