Beware of bad plugins when interacting with `DomainObjectCollection`

[lacasseio]

There are a lot of misbehaving plugins on the portal. The Gradle team has not rollout any quality gate for accepting new plugins which means we need to work around most if not all misbehaviour. Previously, we were relying heavily on addAllLater to defer any computation. Although it's the right way to do this, we easily hit bad plugins such as the Kotlin Plugin. For this reason, we will need to comb our code and ensure that we bridge Nokee and Gradle when entities are finalized at that point it will be fair game. Two things need to happen before we can successfully close this issue: 1) we need to move addAllLater usage to finalize rules and 2) we need to forcefully finalize entities when the bridge is resolved.

For example, we should finalize the backing entities of Configuration domain object instead of realizing them when they are locked by Gradle. We may need to provide a bridge extension on the affected domain objects to allow forceful finalization of the entities. For example, configurations.<some-name>.dependencies.each { ... } may not be enough and would return the wrong set of dependencies. Instead, something like configurations.<some-name>.nokee.finalizeNow().dependencies.each { } may do the work. At the moment, we use three main containers, TaskContainer and ConfigurationContainer everywhere and SourceSetContainer only in JNI plugins.

This work may bleed into the reverse lookup of Gradle object to Nokee entities. There is some consideration with this reverse lookup as multiple Nokee entities can map to a single Gradle object. We are still on the fence with regards to continuing allowing that or simply merging two entities together thanks to the ECS architecture. However, this merge could open the door for nasty misbehaviour like component as Variant (casting component to variant). Those are not actually true but become true in single variant components.

This is definitely not something we should be spending our time on, but the wild universe of Gradle plugins doesn't align with the utopic Gradle usage.