Fix batch publish

[sacOO7]

Related to #197

[AndyTWF]

Does this PR also need to consider a fix for the Http::request method so that the situation described in #197 cannot happen by design?

At the moment if I were to do something like this, it would still cause the server-side encoding errors:

    $payload = array(
        "channels" => ["channel1", "channel2", "channel3", "channel4"],
        "messages" => array(
            "id" => "1",
            "data" => "foo"
        )
    );
    $batchPublishPaginatedResult = $ablyrest->request("POST", "/messages", [], json_encode($payload));

This is because passing a string to AblyRest will cause it not to be encoded any further (we check for !is_string before applying JSON/msgpack), but Http::request will still add the Content-Type header (incorrectly) all the same.

[sacOO7]

@AndyTWF I agree with your point.
Though according to https://faqs.ably.com/do-you-binary-encode-your-messages-for-greater-efficiency, ably uses msgpack as a default encoding.
Also, spec regarding AblyRest->Request is not clear when we recommend msgpack as a default encoding.
It says to accept JsonObject | JsonArray body? as a param ( not a plain string though ). Depending on the useBinaryProtocol clientOptions, encoding will be applied internally.

[sacOO7]

I feel use of type string for payload should be avoided at all cost ( atleast for batch publish ).
We should be documenting the same across SDKs.

[sacOO7]

@AndyTWF I have added note for users wanting to use json => b37daab

[AndyTWF]

I feel use of type string for payload should be avoided at all cost ( atleast for batch publish ). We should be documenting the same across SDKs.

In other SDKs (e.g. Java) we avoid the issue because the body param has to match an interface that can only be one of msgpack or json.

Next time there's a breaking version of this SDK, we should consider enforcing parameters types on the request method (e.g. an array for the params).

[ttypic]

LGTM

[AndyTWF]

I would recommend we keep #197 open as this PR doesn't by design prevent the problem from happening :)