wireproto: use CBOR for command requests Now that we're using CBOR in the new wire protocol, let's convert command requests to it. Before I wrote this patch and was even thinking about CBOR, I was thinking about how commands should be issued and came to the conclusion that we didn't need separate frames to represent the command name from its arguments. I already had a partially completed patch prepared to merge the frames. But with CBOR, it makes the implementation a bit simpler because we don't need to roll our own serialization. The changes here are a bit invasive. I tried to split this into multiple commits to make it easier to review. But it was just too hard. * "command name" and "command argument" frames have been collapsed into a "command request" frame. * The flags for this new frame are totally different. * Frame processing has been overhauled to reflect the new order of things. * Test fallout was significant. A handful of tests were removed. Altogether, I think the new code is simpler. We don't have complicated state around receiving commands. We're either receiving command request frames or command data frames. We /could/ potentially collapse command data frames into command request frames. Although I'd have to think a bit more about this before I do it. Differential Revision: https://phab.mercurial-scm.org/D2951

wireproto: define frame to represent progress updates Today, a long-running operation on a server may run without any sign of progress on the client. This can lead to the conclusion that the server has hung or the connection has dropped. In fact, connections can and do time out due to inactivity. And a long-running server operation can result in the connection dropping prematurely because no data is being sent! While we're inventing the new wire protocol, let's provide a mechanism for communicating progress on potentially expensive server-side events. We introduce a new frame type that conveys "progress" updates. This frame type essentially holds the data required to formulate a ``ui.progress()`` call. We only define the frame right now. Implementing it will be a bit of work since there is no analog to progress frames in the existing wire protocol. We'll need to teach the ui object to write to the wire protocol, etc. The use of a CBOR map may seem wasteful, as this will encode key names in every frame. This *is* wasteful. However, maps are extensible. And the intent is to always use compression via streams. Compression will make the overhead negligible since repeated strings will be mostly eliminated over the wire. Differential Revision: https://phab.mercurial-scm.org/D2902

wireproto: syntax for encoding CBOR into frames We just vendored a library for encoding and decoding the CBOR data format. While the intent of that vendor was to support state files, CBOR is really a nice data format. It is extensible and compact. I've been feeling dirty inventing my own data formats for frame payloads. While custom formats can always beat out a generic format, there is a cost to be paid in terms of implementation, comprehension, etc. CBOR is compact enough that I'm not too worried about efficiency loss. I think the benefits of using a standardized format outweigh rolling our own formats. So I plan to make heavy use of CBOR in the wire protocol going forward. This commit introduces support for encoding CBOR data in frame payloads to our function to make a frame from a human string. We do need to employ some low-level Python code in order to evaluate a string as a Python expression. But other than that, this should hopefully be pretty straightforward. Unit tests for this function have been added. Differential Revision: https://phab.mercurial-scm.org/D2948

wireproto: explicit API to create outgoing streams It is better to create outgoing streams through the reactor so the reactor knows about what streams are active and can track them accordingly. Test output changes slightly because frames from subsequent responses no longer have the "stream begin" stream flag set because the stream is now used across all responses. Differential Revision: https://phab.mercurial-scm.org/D2947