Apache Connector connection pooling is not supported properly

This issue has the same result as: [https://java.net/jira/browse/JERSEY-2157](https://java.net/jira/browse/JERSEY-2157)
but the source cause is different.

In Jersey Client's JerseyInvocation.java ([https://github.com/jersey/jersey/blob/927b4d0605aeb119d15e9623dab65c8aec2c8e20/core-client/src/main/java/org/glassfish/jersey/client/JerseyInvocation.java#L943-L953](https://github.com/jersey/jersey/blob/927b4d0605aeb119d15e9623dab65c8aec2c8e20/core-client/src/main/java/org/glassfish/jersey/client/JerseyInvocation.java#L943-L953)), if the callbackParamClass is of type **Response.class**, the resulting logic **fails** to consume or read the entity. It simply casts the response as an **InboundJaxrsResponse**.

This causes connection-pool starvation when using certain connectors (such as the ApacheConnector), which rely on the entity being "consumed" to release the connection back into the pool, and hitting JERSEY-based servers that return **Response** objects instead of actual entities.

I included the other "bug" to show how it was resolved: [https://github.com/jersey/jersey/blob/927b4d0605aeb119d15e9623dab65c8aec2c8e20/core-client/src/main/java/org/glassfish/jersey/client/JerseyInvocation.java#L995-L999](https://github.com/jersey/jersey/blob/927b4d0605aeb119d15e9623dab65c8aec2c8e20/core-client/src/main/java/org/glassfish/jersey/client/JerseyInvocation.java#L995-L999)

In essence, on a non-200 response, **response.bufferEntity()** is called to notify connectors, such as the ApacheConnector, that the entity has been "consumed" and that it should release the current connection back into the Apache ConnectionManager pool (if being used).

I think a similar code-fix needs to be implemented for a successful 200 response that returns a Response object.

I have resorted to calling **response.bufferEntity()** in all my callbacks and response-handling code to prevent my ApacheConnector pool from suffering from connection starvation because connections are never released.

This issue doesn't affect JERSEY Server REST endpoints that return anything other than Response (unfortunately the JERSEY Server returns Response objects for all "async" server REST handlers...which in our case is quite a few).
#### Environment
Mac OSX 10.11.4; DropWizard 0.9.2;
#### Affected Versions
[2.23.1]

Start in core-client/src/main/java/org/glassfish/jersey/client/JerseyInvocation.java at the cited callback handling and compare it with the nearby non-200 response logic. Reproduce a successful response callback using Response.class with the ApacheConnector, then verify that the connection is released back to the pool without requiring callers to invoke bufferEntity().

Written by the indexing model from the issue text.