anchor.diff:  * A teacher prefers to teach every lesson in a single room.
   * A teacher prefers to teach sequential lessons and dislikes gaps between lessons.
   
  -Mathematically speaking, school timetabling is an _NP-hard_ problem. This means it is difficult to scale. Simply using brute force to iterate through all possible combinations would take millions of years for a non-trivial data set, even on a supercomputer.
  +Mathematically speaking, school timetabling is an _NP-hard_ problem.
  +This means it is difficult to scale.
  +Simply using brute force to iterate through all possible combinations would take millions of years for a non-trivial data set, even on a supercomputer.
   Luckily, AI constraint solvers such as OptaPlanner have advanced algorithms
   that deliver a near-optimal solution in a reasonable amount of time.
   
  
positive.code: 
  The `timeslotList` field is a value range provider.
  It holds the `Timeslot` instances which OptaPlanner can pick from to assign to the `timeslot` field of `Lesson` instances.
  The `timeslotList` property has an `@ValueRangeProvider` annotation to connect the @PlanningVariable with the @ValueRangeProvider,
  by matching the value of the `id` property with the value of the `valueRangeProviderRefs` property of the `@PlanningVariable` annotation in the `Lesson` class.
  
  Following the same logic, the `roomList` field also has an `@ValueRangeProvider` annotation.
  
negative.code: It also verifies that it found a feasible solution (no hard constraints broken).
  
  Normally, the solver finds a feasible solution in less than 200 milliseconds.
  Notice how the `@SpringBootTest` annotation's `properties` property overwrites the solver termination
  to terminate as soon as a feasible solution (`0hard/*soft`) is found.
  This avoids hard coding a solver time, because the unit test might run on arbitrary hardware.
  This approach ensures that the test runs long enough to find a feasible solution, even on slow machines.
  