Ensure data consistency between REST API responses and WSS broadcasts

[andrewnoyes]

This was something I noticed related to updating a carpool, specifically its name, description, location, or time (not its metadata). When one of those fields were updated, it resulted in a carpool:updated event that would overwrite the metadata property of the carpool. This would then display the drivers/seats remaining being reset to 0, because that field hadn't been populated due to it being handled via a separate event. This was fixed (hackyish) in PR #164, but I think it speaks to a broader issue of how we handle responses from API calls and their subsequent WSS events that are broadcast.

The web client relies heavily on WSS events that are broadcast to update its state, and usually ignores the responses returned from the API calls. This isn't the biggest deal, but I think it relates to #162. For example, if I join a driver as a passenger and for whatever reason I don't have an active websocket connection, then the UI will not be updated - even if I made a successful API call to join and received a valid response.

I think we should ensure that all API calls that receive the same response they would be receiving over a websocket broadcast should be using the response value to update client state. On the backend, I think it'd also be a better practice to return the response to client and then broadcast a WSS update to all clients except the connection that sent it. This is so the client doesn't receive duplicate updates, and we're actually using the REST API... or we could just refactor the whole thing to only use websockets 😜 (just kidding)