Fix a flaky test (#1204)

In testSuccess_expandSingleEvent_notIdempotentforDifferentRecurring(),
two Recurring entities are created with the only difference being their IDs. If
we don't order the Recurrings by ID when loading them there is no guarantee
which one is expanded first. In this test the expected OneTime entities are
created with the assumption that the first loaded DomainHistory (parent of a
OneTime) corresponds to the expanding the Recurring with the smaller ID (2L).
Since the DomainHistory entities are loaded in order of IDs, and the IDs are
created monotonically in time in tests, we need to load the Recurrings in
order of their IDs to ensure that the first DomainHistory is the result of
expanding the Recurring with ID of 2L. This should impose minimum performance
penalty as we are ordering by the primary key.

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/google/nomulus/1204)
<!-- Reviewable:end -->

core/src/main/java/google/registry/batch/ExpandRecurringBillingEventsAction.java

@@ -127,10 +127,11 @@ public class ExpandRecurringBillingEventsAction implements Runnable {
                       jpaTm()
                           .query(
                               "FROM BillingRecurrence "
-                                  + "WHERE event_time <= :executeTime "
-                                  + "AND event_time < recurrence_end_time",
+                                  + "WHERE eventTime <= :executeTime "
+                                  + "AND eventTime < recurrenceEndTime "
+                                  + "ORDER BY id ASC",
                               Recurring.class)
-                          .setParameter("executeTime", executeTime.toDate())
+                          .setParameter("executeTime", executeTime)
                           // Need to get a list from the transaction and then convert it to a stream
                           // for further processing. If we get a stream directly, each elements gets
                           // processed downstream eagerly but Hibernate returns a