race condition with messages to/from weston-launch

We ran into an intermittent issue where weston will encounter an error if we switch the virtual terminal too quickly. In analyzing the code, we realized that there is a race condition inherent with the current design.

The race condition occurs when weston sends the WESTON_LAUNCHER_OPEN message to weston-launch and receives the corresponding fd handle value. The WESTON_LAUNCHER_OPEN message would have been triggered by the WESTON_LAUNCHER_ACTIVATE message sent from weston-launch. The problem is that if weston-launch receives a VT_RELEASE signal from the kernel before it receives the WESTON_LAUNCHER_OPEN message from weston, then weston-launch will send the WESTON_LAUNCHER_DEACTIVATE message when weston is going to be expecting the fd handle value next.

The inherent problem here is that both weston-launch and weston can asynchronously send messages at any point in time, but weston expects that after sending WESTON_LAUNCHER_OPEN, that weston-launch will always respond with the fd handle value reply.

One solution would be to open 2 sockets pairs and use one for asynchronous message initiated by each endpoint. Another solution would be to reserve a msg id for the WESTON_LAUNCHER_OPEN reply and modify weston to receive it asynchronously somehow.