`Map.replace(K, V, V)`: Make `oldValue` `@Nullable`

[cpovirk]

We have it as parametric nullness in Map itself and in ConcurrentMap and presumably other subtypes:

• jdk/src/java.base/share/classes/java/util/Map.java

  Line 955 in 39339b0

  default boolean replace(K key, V oldValue, V newValue) {

• jdk/src/java.base/share/classes/java/util/concurrent/ConcurrentMap.java

  Line 226 in 39339b0

  boolean replace(K key, V oldValue, V newValue);

Android has it as @Nullable: https://cs.android.com/android/platform/superproject/main/+/main:libcore/ojluni/annotations/sdk/nullability/java/util/Map.annotated.java;l=72;drc=31fc4306a5baa196245ae16f79009b632ccbe667

As a result of that difference, an Android nullness check in Google's depot gets upset.

It seems like @Nullable would make sense, given the concept of the method and the default implementation: You can't hurt anything by passing null.

But that might be trouble for Kotlin? https://github.com/JetBrains/kotlin/blob/e32761ba660d67e60ddcd3cd1e798331b9f6d9d3/core/compiler.common.jvm/src/org/jetbrains/kotlin/load/java/typeEnhancement/predefinedEnhancementInfo.kt#L169-L174

And we'd want to see if at least some implementations would reject null, similar to contains. (That likely wouldn't change our direction for the interface, but we'd want to keep the type with parametric nullness (or make it non-null) for any such implementations.)

[cpovirk]

But that might be trouble for Kotlin?

Then again, the existing Android annotation doesn't seem to be causing trouble.

(We had trouble with mismatches between our annotations and Kotlin's idea of how some JDK methods should be annotated before. But I think that was under K1, and I'm not sure if I ever figured out for sure whether there was actually a bug in K1 that made things worse than they were meant to be.)