HTTP redirect as per specification

[fjtirado]

Currently, user can provide custom Http clients different than the used library (jersey, resteasy..) default one through the usage of WorkflowAdditionalObject.

Although users already has access to the task object (as part of TaskContext and and hence the timeout and redirect) this does not ensure that those users will took into account the timeout and redirect config as specified in the task.

Since there are JAXRs implementations that allows the timeout to be changed per request (as Jersey does), potentially reusing one single client and there are others (as RestEasy) that requires the timeout to be set before the client is actually created (implying one different client for request), what we can do is:

• Change the HttpClientResolver mentioned code to also expect a ClientBuilder (besided the Client), if the user return a CliendBuilder, we can then set the timeout over that ClientBuilder and then build the client (this has the additional advantage of allowing closing the client once it has been used). If a Client is returned, then nothing is done.
• User can additionally include a new HttpRequestConfigurer implementation(tipically one per application, see ConstantAdditionalObject), where they can change the request setting timout and redirect properties, the implementation will invoke setTimeout and setRedirect over each request if this interface has been provided.

[fjtirado]

After a second thought, It is not longer clear to me that the we should make the task timeout equal to http timeout if the task is an http one. Basically because since we are allowing users to setup the http client through additional object mechanism, it might potentially collide. Probably it would be good to change the scope of this issue just to handle the redirect. @ricardozanini lets take a look when you can.