Improve Java-Client Tests and CI

Created by: jmini

Input @MatanRubin on #513 (closed):

this was a serious bug in a very basic scenario for a very common library (i.e. the generated client fails a simple GET for Java + RestTemplate). Don't we have tests that cover this kind of scenarios for all languages and libraries? Not trying to blame anyone here, just asking out of curiosity and to see maybe I can contribute some tests that will help prevent this kind of issues.

Well the more I am confronted with changes to java-client templates, the more I think we need to do a real setup.

I theory some of the Java-Client have some tests for clients implemented (replacement of the generated stup) that perform test against some server serving the "Petstore sample". During the creation of OpenAPI-Generator, some of them were removed => #247. This reminds me that I should finish restoring them.

But this is not enough... Have a look at the PR I have merge this morning: #646. It is about special chars being wrongly encoded in query-params. A test case would be ideal for that.

We need a setup where we can control the server for each test. Using the generated code (XxxxApi) we send a request and we create expectations on what should arrive to the server. Or in the server we define what should be returned and we see if the client did interpret the answer correctly.

I am wondering which library can be used to do something like this. Easy embedding of a small HTTP-Server. I have started to have a look at https://github.com/arteam/embedded-http-server, I can't imagine that there is not something. (it is not about mocking the server, but having a simple one where we can perform assertions on request that arrived and were we can control the answer).

Any suggestions?

Then I think that we should generate client for all libs we support. I started something in this direction: https://github.com/jmini/openapi-experiments/tree/master/openapi-generator-utils/icespellmint. The spec used to create the client will be updated to test a lot of cases we have (all HTTP verbs like "GET", "POST", "PUT"..., with or without parameters, with different supported content-type (json, text, xml)).

This way we can control if something is an improvement or creates some regressions.

There is an other interesting issue: #476, I have started to work on this, but again I want to have a great coverage to be sure that I am not breaking anything.

Feedback is welcomed.