JVM dependency conflict resolution bug

[ekravchenko]

Describe the bug
When there is any conflict (even not critical) among dependencies versions - pants v2 will just remove conflicting library from classpath. Compilation might succeed but application will fail at runtime with NoClassDefFoundError (which is very dangerous)

Steps to reproduce:

1. Add dependency to cats-effect version 3.3.14 -> org.typelevel:cats-effect_2.13:3.3.14
2. Create simple Main file:

package example

import cats.effect.{IO, IOApp}

object Main extends IOApp.Simple {

  override def run: IO[Unit] = IO(println("Hello world!"))
}

3. Add cats-core library in 3rdparty with version 2.8.0 -> org.typelevel:cats-core_2.13:2.8.0. The problem is that cats-effect depends on cats-core version 2.7.0 and that creates a conflict.

But why add cats-core 2.8.0 ??? The truth is that this sort of conflict will appear in many Scala libraries transitively. For example try doing cs resolve -t org.typelevel:log4cats-core_2.13:2.5.0. Coursier thinks that cats-effect is incompatible with cats-core version 2.8.0 (which is not true).

On top of that the biggest problem is that pants is not reporting conflicts during build time. Build will be green but application will fail at runtime with

Exception in thread "main" java.lang.NoClassDefFoundError: cats/kernel/Semigroup

It would be great to see someday several conflict resolution strategies (see https://www.scala-lang.org/2019/10/17/dependency-management.html), but as a quick fix - strict resolution with build failure on transitive dependencies conflicts and verbose problem reporting should work

Pants version
2.13.0

OS
MacOS Monterey

Additional info
Sample project where dependency conflict resolution leads to runtime error: https://github.com/ekravchenko/dependency_example
(same project attached below)

dependency_example.zip