Resolve ambiguity on "Waiting confirmation" booking status for booking by API

[adelcasse]

Booking requests have a status to describe the state in the workflow of the booking. The first (or second after PR #50) status in the workflow is WAITING_CONFIRMATION.

We faced an issue with this while implementing bidirectional interoperability.

In the case of a bidirectional interoperability between a MaaS and a carpool operator (a user from the MaaS can book a journey from the operator, and a user from the operator can book a journey from the MaaS), the WAITING_CONFIRMATION state is ambiguous. By reading the booking status, we cannot tell if we are waiting for a confirmation from the MaaS or from the operator, as it doesn't specify if we are waiting for a response from the driver or the passenger.

The introduction of a booking status INITIATED proposed in PR #50 makes it problematic even in the case of a "one way" relationship between the MaaS and the operator (only initiate booking from the MaaS to a journey on the operator, and not the other way), as :

• The MaaS could create a booking to set a status as INITIATED first, to send a message
• Both the operator or the Maas could patch the status to WAITING_CONFIRMATION

In this case, it will also be ambiguous and we won't know by reading the booking state which platform/user has to confirm

To resolve this ambiguity, we propose to :

• Remove WAITING_CONFIRMATION in the bookingStatus enum
• Replace it with unambiguous "WAITING_DRIVER_CONFIRMATION" and "WAITING_PASSENGER_CONFIRMATION"