Developer's notes for SPR 754
Marnix Bindels, March 29 2006

In order to distinguish HANDOVER from RHANDOVER, I introduced 'specified
handover' versus 'recommended handover'.

The HandOverWindow class extends ConstraintEvent and hence inherits the
verifiedShift() method. This method is used to decrease gap sizes during
schudling by moving an event on the timeline while respecting the UI setting
'Fix GSHO'. The effects of SPR754 could have been caused by this method as the
fact that the HandOver was not recommended but specified is unknown in
ConstraintEvent context and subsequently ignored. Part of the solution has been
to override verifiedShift in HandOverWindow to take the recommended flag into
account.

The handleStaringExposureClashEvents() method will move event coinciding with
the exposure in cases where such improves the schedule. The method uses
EventList.shiftEvent() which performed local and insufficient constraint
checking (ignoring both UI fix flag and the recommended flag). This has been
changed by having shiftEvent using the ContraintEvent's verifiedShift() method.

The EventList.shiftEvent() method was an exception sink, shielding all internal
Exceptions. This behavior has been improved, which changes its operation: the
method throws SchedulingException and is now able to shift head and tail events
too. The SchedulingException thrown while shifting an Event that's not in the
EventList (silently caught in the former version) would now surface. However,
shiftEvent() is only referenced from handleStaringExposureClashEvents() in which
the events to be shifted are guaranteed to be in the EventList. All other
exceptions that were formerly caught silently, will be visible in the future
scheduling sessions - whether that is useful needs to be evaluated in practice.

The POSChecker has been augmented with a check asserting the pattern of
DEBPG200; HANDOVER_START; DEBPG200; HANDOVER_STOP for all handovers in the POS.
It does so by a sort of state machine starting in state 1 and moving to 2, 3 , 4
and 1 again on encountering the expected entry, and moving to state 5 -error- on
a non-expected entry (ignoring any other command than the 4 mentioned above).
The POSCheck error message contains the timestamp of the first offending
command.