Add an ApproveChange scenario and base the SubmitChange scenario on it.
Make the ApproveChange scenario runnable alone as well. In this case,
allow the change number being approved to be set through the existing
'number' test environment property; cf. [1]. In the other case of
running approval from SubmitChange, set the change number automatically.
Adapt the existing standalone DeleteChange scenario, for SubmitChange.
That scenario showed to be very similar to the added ApproveChange one.
Adapt the existing standalone CreateChange scenario, so it can be run
from SubmitChange now as well. Make the CreateChange project field no
longer automatic or solely set by CreateChange alone. Instead, make it
either set from composing scenarios such as SubmitChange or as per [1].
Enable this all by making CreateChange a core ProjectSimulation now.
Rather than having DeleteChange hold the change number, move it to the
CreateChange class. Enable this new SubmitChange scenario flow that way,
while preserving existing scenario abilities. Having the CreateChange
scenario generate *and* hold the resulting change number should also be
more intuitive, compared to DeleteChange holding it before.
[1] https://gerrit-documentation.storage.googleapis.com/Documentation/2.16.19/dev-e2e-tests.html#_environment_properties
Change-Id: I86dda57672ef9f34a286bfd151226b5988cb7a34
24369c8d9c