Fix Servlet instrumentation for servlet-api 3.1+ - remove output stream wrapper

[mateuszrzeszutek]

Fixes #1083

The third time's the charm, I hope. This PR contains removal of the ServletoutputStream wrapper according to this comment.

This might be not so bad anyway, because according to ServletResponse#getOutputStream() JavaDoc:

     * Either this method or {@link #getWriter} may 
     * be called to write the body, not both.

so only those implementations that use getOutputStream() will get inaccurate content sizes (always 0), while those using getWriter() will be perfectly fine.

[FrankSpitulski]

Can you add a unit test that succeeds now but if the wrapped response were to be used would fail so that there will be no regressions?

[mateuszrzeszutek]

Can you add a unit test that succeeds now but if the wrapped response were to be used would fail so that there will be no regressions?

I can do a simple instanceof check -- the same way as it was handled in JettyHandlerTest for a similar issue.
Calling either ServletOutputStream#isReady() or ServletOutputStream#setWriteListener() would be ideal, but unfortunately I cannot do that without bumping servlet api version.

[iNikem]

Taking into account #1096 (comment) and #1083 (comment) I propose to completely remove generic response counting support from servlet instrumentation. I feel bad about this, but if we are left with a partial solution (as @FrankSpitulski noticed above "it misses spring boot's default configuration"), then added complexity is not worth it. History has shown, that this is not as easy as we would like :(

Unless somebody has a good proposal how to solve this otherwise, I ask @mateuszrzeszutek to remove CountingHttpServletRequest, CountingHttpServletResponse and all related functionality for the time being.

[mateuszrzeszutek]

OK, I've removed all Counting* classes.

[anuraaga]

Thanks @mateuszrzeszutek!

@FrankSpitulski Really sorry about this >< Thanks a lot for the help and giving us the opportunity to think through some of the problems regards to instrumentation here, we may not have noticed that Muzzle needs additional checks related to base-class matching without this exercise so will hopefully get better.

[mateuszrzeszutek]

we may not have noticed that Muzzle needs additional checks related to base-class matching without this exercise so will hopefully get better.

There's an issue for that now: #1123 . I have an idea how to do implement that, so hopefully this will get done soon and we'll avoid similar issues in the future.