base: When buffering keep entire block if not consumed

We already went through the work of combining the message when
doing a buffer callback. So keep the result around if the callback
didn't consume anything.

Reviewed-by: Marius Vollmer <marius.vollmer@redhat.com>
docker: Use streaming functionality in docker console

This makes things more efficient although it doesn't completely cleanup
the ugliness in this code. The reality is that the Docker attach
stream is pretty nasty, and that's reflected here.

Reviewed-by: Marius Vollmer <marius.vollmer@redhat.com>
common: Allow skipping bytes after in cockpit_pipe_consume()

Reviewed-by: Marius Vollmer <marius.vollmer@redhat.com>
bridge: Consistent parsing of address channel options

So we have consistent handling for both stream and the upcoming
http-stream1 channels.

Reviewed-by: Marius Vollmer <marius.vollmer@redhat.com>
bridge: Allow connecting back to the test-server port in tests

This does implement a general mechanism for addressing internal
things that the bridge knows about, that don't have a stable
port or unix path address. Would like to make more use of this
in the future, but for now just implement the test-server port
as an internal address.

Reviewed-by: Marius Vollmer <marius.vollmer@redhat.com>
ws: Remove incorrect comment about chunked encoding

We don't need to support receiving chunked encoding in
CockpitWebServer because we never receive any HTTP body here,
no POST requests etc...

Reviewed-by: Marius Vollmer <marius.vollmer@redhat.com>
base, bridge: Implement new http-stream1 channel payload

Implement a new payload called 'http-stream1' which makes an
HTTP request. The channel encapsulates one HTTP request.
Various options accompany the "open" control message. The
first payload message is the response headers.

Add a new cockpit.http() API as well

Reviewed-by: Marius Vollmer <marius.vollmer@redhat.com>
docker: Add docker.json_skip() function

This lets us separate a JSON stream into blocks using javascript
similar to what the cockpit_json_skip() C function does.

This is currently Docker specific, since I don't know of any other
code that does silly things like sending invalid JSON data but
still treating it as application/json.

But that may change in the future, silly things abound. So then we
might move this code into cockpit.js.

Reviewed-by: Marius Vollmer <marius.vollmer@redhat.com>
shell: Port the docker code to use cockpit.http()

And stop using rest-json1 payload.

Reviewed-by: Marius Vollmer <marius.vollmer@redhat.com>
bridge, shell: Remove the old rest-json1 code

Closes #1519
Reviewed-by: Marius Vollmer <marius.vollmer@redhat.com>
docker: Batch updates to the docker console logs

This is necessary when transferring large amounts of log data

Closes #1550
Reviewed-by: Marius Vollmer <marius.vollmer@redhat.com>
base: Don't kill stream buffer callback when nothing has been consumed

Reviewed-by: Stef Walter <stefw@redhat.com>
shell: Fix Docker 'attach' header parsing.

* Return zero when the buffer isn't big enough yet.  Returning
  'undefined' means that everything was consumed.  (I have not
  actually observed this; the first message always seems to include
  the whole header.)

* Handle the return value of view.process.  It might not consume
  everything.

  We can not simply not call view.process and "return pos+4" to let
  the channel deal with this.  A buffer callback is required to
  consume as much as it can.

Closes #1553
Reviewed-by: Stef Walter <stefw@redhat.com>
Bump version number
bridge, base: New 'options' control message

This is a new control message that is sent in a channel, and changes
the state or options of the channel. The cockpit javascript channel
API is also adjusted to make it easier to send control messages.
bridge: Add 'batch' and 'latency' advise options in stream

These are 'tell' message options, which let the caller change
the stream batching and latency on the fly. Necessary for the
docker console and journal logging.
docker: Use the 'batch' and 'latency' stream options

These allow the docker logs to have some semblance of performance
when loading large amounts of data.
server-systemd: Use the "batch" and "latency" options in journal code

These should allow transferring data in larger blocks unless the
given latency is reached. A bit more efficient when parsing things.