Support more content types

[letmaik]

Fixes #1554.

Inside a JS endpoint:

• Request body is a Body object which is similar to https://developer.mozilla.org/en-US/docs/Web/API/Body, except that it has a synchronous API and only offers .text(), .json(), and .arrayBuffer().
• Response body can be a string, a JSON-serializable object, a typed array object, or an ArrayBuffer object. The type decides the response content type. In the future, an API should be added so that the endpoint can override the default content type. Note that previously strings were serialized as JSON -- this doesn't happen anymore as it's generally not what you want.

Using the Python client (and hence in unit tests):

• Request body can now be str, bytes, and all other types are assumed to be JSON. The type determines the default content type (text/plain, application/octet-stream, application/json). If the body is a str starting with @ then it is only assumed to be JSON if the filename ends with .json -- no JSON parsing is done here, this is just for determining the default content type.
• Response body is str (for text/plain), a parsed JSON object (for application/json), or else bytes.

[ghost]

letmaik/bytes-payload@12388 aka 20200908.8 vs master ewma over 50 builds from 11852 to 12368

[achamayou]

The view here is that websockets is the efficient option, and it is the efficient option because it does away with the large variable header. Endpoints are expected to expose their schema out of band rather than send (or expect) self-describing traffic.

An application that wishes to replicate the content-type concept across their websockets endpoints would do so in the outer frame of their schema.

[letmaik]

So, is it fine to keep the try-except? If not, then maybe for WebSocket it should always return bytes?

[achamayou]

We probably should, but then we have to adjust the logging test accordingly. Let's keep it as is and do that clean up in a separate PR?

[letmaik]

#1584

[letmaik]

While changing the npm app to use the new Body class I stumbled upon an issue when returning ArrayBuffer: protobufjs returns an Uint8Array with byteLength 14 and the underlying ArrayBuffer has a byteLength of 8192, which means we should probably also accept typed arrays as return values to avoid potential issues where a slice was taken and the lengths would mismatch. I'll see if quickjs has the necessary APIs to deal with typed arrays.