[haskell-http-client] Add new haskell-http-client client generator

[jonschoning]

PR checklist

• Read the contribution guidelines.
• Ran the shell script under ./bin/ to update Petstore sample so that CIs can verify the change. (For instance, only need to run ./bin/{LANG}-petstore.sh and ./bin/security/{LANG}-petstore.sh if updating the {LANG} (e.g. php, ruby, python, etc) code generator or {LANG} client's mustache templates). Windows batch files can be found in .\bin\windows\.
• Filed the PR against the correct branch: master for non-breaking changes and 3.0.0 branch for breaking (non-backward compatible) changes.

Description of the PR

Adds new generator template haskell-http-client (HaskellHttpClientCodegen.java) which generates a client library for Haskell.

The existing Haskell generator uses servant as the framework to generate bindings.

In contrast, this uses http-client which is a more low-level/fundamental http library.

Another unique thing about this generator is that it ensures at compile-time that the content-type & accept headers and associated encoders / decoders and are within the specified Produces and Consumes for a given Operation.

A sample is provided at samples/client/petstore/haskell-http-client along with

• unit tests (serialization)
• integration tests
• example app

Currently Unsupported Swagger Features

• Auth Methods
  • headers may be added manually by user
• Default Parameter Values
• Enum Parameters
• ./bin/security/{LANG}-petstore.sh

All petstore operations are currently succeeding with http status 200 ok (integration tests).

Expecting a few WIP updates

[wing328]

@jonschoning I couldn't get the CI (travis) working: https://travis-ci.org/swagger-api/swagger-codegen/builds/271606980

I'll try to fix it later as part of the future enhancement to this generator.

[wing328]

Tweet to promote the new generator: https://twitter.com/wing328/status/905108552464793600

[jonschoning]

re: CI (travis):

the haskell bits of the build in fact succeeded without any errors.
the normal tests completed on line 6683

Finished in 0.2569 seconds
6 examples, 0 failures

the integration tests completed on line 6778

Finished in 0.6834 seconds
20 examples, 0 failures

what is happening, is that setting up the haskell compiler bits is adding some time, which is causing the whole job to exceed the max time allowed in conjunction with all the other samples/tests that being run.

What I've found with travis, is that

• the first time stack is run and must download the haskell compiler (ghc) and the base packages, which adds about 13 minutes to the build time (example: https://travis-ci.org/jonschoning/swaggerpetstore-haskell-http-client/builds/269008795 note: this is on a default travis ubuntu linux box; I am not sure if the osx boxes have the same performance)
• if this first build succeeds and is able to store the ~\.stack directory into the travis cache, then on subsequent builds, if the cache is retrieved successfully, there is no need to download/install ghc (it is retrieved from the cache) and the whole build finishes in less than 2 minutes (https://travis-ci.org/jonschoning/swaggerpetstore-haskell-http-client/builds/269255239)

It would have to complete an entire travis build, to get the cache updated (it only uploads the cache at the very end). Since I don't think caches are shared between branches, that makes it kind of tricky to decide which sample targets to run.

For now, I suggest leaving the haskell tests commented out because of this time issue. if desired, testing haskell via travis CI would be possible by reducing which sample targets are run, so that the max time isn't exceeded (but I'm not sure that's a desirable option for the master swagger-codegen branch).