Review protocol for consistency

[jasongrout]

With #1207, it is painfully clear that we should review the protocol messages for consistency. For example, the sync messages are needlessly different depending on the direction between the backend and the frontend.

Also, it's very weird that the comm_open messages from the frontend to the backend give a magic string, but the comm_open messages from the backend to the frontend just give the state. I think the problem here is that you can have multiple kernel-side implementations of the same syncing data model (like IntProgress and FloatProgress I believe use the exact same javascript model with different defaults). This is especially weird since each model on the front end should have the same defaults as the model in the kernel, but can't if there is a one to many relationship. Perhaps we should insist on basically having a 1:1 correspondence between frontend and backend models, so that the synced attributes define the widget.

• Review the comm_open message to make it symmetric: Start to unify the comm_open messages in the spec. #1228.

[jasongrout]

Some of the inconsistency (in how buffers are used) is taken care of in #1194, thanks to @maartenbreddels great efforts!

[SylvainCorlay]

There are some intrinsic reasons for some of the asymmetry. The request state message only makes sense from the front end to the backend. (The front-ends eventually can become transient and the backend long living.)
I agree on other items but symmetry is not required everywhere.

[jasongrout]

Yep, +1 to the request state message staying asymmetric.

[jasongrout]

This is now done with the merge of #1228.