Yet another booking flows merge trial

[osarrat]

Yes, let's dare !

Its is opened for discussion tomorrow...

[pierrecamilleri]

As a result of the discussions of our last meeting, we agreed that some work on the names should be useful to make sense of the different Booking objects. I write down the suggestions that we had during this meeting :

• GenericBooking instead of CarpoolBooking (everybody seems to agree)
• TransactionalBooking or BookingTransaction or BookingRequest

Some opinions that have been expressed :

• BookingTransaction sounds better than TransactionalBooking BUT the first breaks the expectation given by the endpoint name /bookings while the second does not.
• BookingRequest sounds confusing, as it is not only used during the first request, but also at all stages until the trip is completed.

[pierrecamilleri]

As disussed today, this PR needs further discussions.

• Underlying data structure changes (e.g. GenericBooking) can be done in the future without breaking the API calls.
• Changing the object names can also be done with few changes in the implementation and can be considered as long as the standard is informative.

So these changes are not yet merged for a v1 informative version.

[ccyrille]

This PR introduces some unidentified breaking changes regarding the booking events flow (#5). I think this shows quite well that trying to merge the objects for the booking by API / booking events flow is far from an easy job and should be done "a posteriori" (when standard will be stabilized <> modules will be staged for the "normative" part).

[ccyrille]

This change is not compatible with the booking events flow (#5) as the passenger / driver will not be known on MaaS's side.

[ccyrille]

This change is not compatible with the bookings events flow (#5) as the passenger / driver will not be known on MaaS's side.

[ccyrille]

If marked as optional here, it must be clear that it is mandatory for the booking events flow (#5).