client: remove support for custom request Content-type

[pablopalacios]

GET requests do not have a content, so no content-type header needed.

POST requests, in theory, could have any content-type since users could use any kind of express middleware that would populate req.body. The only use case that I see is to upload pictures. One could use a multipart form data to do that. But this person would need to know fetchr middleware implementation in order to make it work properly. But I bet that we all know better options to upload media that would be easier than to hack fetchr.

So, IMO, it doesn't make sense to provide this feature. Am I missing something?

What I'm trying to do now is to make the requests/responses as consistent as possible so we can simplify the code. I'm mainly concerned about error handling, this is where the code here is the ugliest IMO. The error object is inconsistent for different kinds of errors. This makes it hard to build proper errors handlers (ex. an integration with newrelic, sentry or any custom error dashboard).

I confirm that this contribution is made under the terms of the license found in the root directory of this repository's source tree and that I have the authority necessary to make this contribution on behalf of its copyright owner.

[redonkulus]

This code was there from the start, I'm not sure what the original intent was. I'm fine removing it, unless @lingyan can remember any of the history.

[pablopalacios]

@redonkulus from what I see, the http module was a generic one. One could use it not only for fetchr since it's only wrapping fetch (or xhr previously). If you remember, there was even support for PUT and DELETE requests (see #273 ), even though fetchr itself never required it.