Begin migration of joda DateTime to java.time.Instant (#2992)

java.time has been around since Java 8 and was based on joda DateTime, so this
is an overdue migration.  We're migrating specifically to Instant in most places
rather than ZonedDateTime because we were always using DateTimes in UTC to
reference a specific instant, which is exactly what Instants are
for. ZonedDateTime set to UTC may still be useful in some places that are heavy
on date math (especially in tests).

There is a lot more work to be done after this, but I wanted to put together a
manual PR showing my overall approach for how to do the migration that I can
then hopefully follow along with AI to continue making these changes throughout
the codebase. The basic approach is to migrate a small number of methods at a
time, marking the old methods as @Deprecated when possible (not always possible
because of @InlineMe restrictions). This PR doesn't yet migrate any DateTime
fields in the model classes, so that's the one remaining type of refactor to
figure out after this. We won't be changing how any of the data is actually
stored in the database.

BUG= http://b/496985355

common/src/testing/java/google/registry/testing/FakeClock.java

@@ -19,6 +19,7 @@ import static org.joda.time.DateTimeZone.UTC;
 import static org.joda.time.Duration.millis;
 
 import google.registry.util.Clock;
+import java.time.Instant;
 import java.util.concurrent.atomic.AtomicLong;
 import javax.annotation.concurrent.ThreadSafe;
 import org.joda.time.DateTime;
@@ -54,6 +55,11 @@ public final class FakeClock implements Clock {
     return new DateTime(currentTimeMillis.addAndGet(autoIncrementStepMs), UTC);
   }
 
+  @Override
+  public Instant now() {
+    return Instant.ofEpochMilli(currentTimeMillis.addAndGet(autoIncrementStepMs));
+  }
+
   /**
    * Sets the increment applied to the clock whenever it is queried. The increment is zero by
    * default: the clock is left unchanged when queried.