Correctly clean up memory attributes and file uploads - #9672

Can one of the admins verify this patch?

@netty-bot test this please

@netty-bot test this please

Fixed tests

@netty-bot test this please

@jameskleeh @fredericBregier seeing that we need to adjust tests I now wonder if it may break some users code :/ ?

@jameskleeh @normanmaurer Indeed, I had the same in my mind...

Previously, any HttpData should be released once used (as any ByteBuf should be), but a specific cleanup was done on "file" data, in order to keep disk usage under control.
The new idea was to add the "memory" too to this cleanup. But it seems it brings some issues. I was believieng that it shall not raised any issue since call twice the release on HttpData will not release twice the ByteBuf. But the changed tests seem to show the contrary.

In order to keep the previous orientation, we might introduce 2 things:

• one additional list that keep trace of all HttpData, whatever disk based or memory based
• one additional method to clean everything, based on this new list

Doing this will preserve the previous semantic, but still having the possibility to clean all and everything if needed.

WDYT?

I think if another method is introduced for this, that method should be deprecated in the next major release and the existing methods should be changed. Just let me know how you all want to proceed

@jameskleeh Changing to deprecated to removal is a long way (depends on what is a major version of course).
I believe it is difficult to add a new method that is from the beginning "deprecated". From an external point of view, it seems strange (even if I understand the reason why and seems correct).
Maybe adding the new method with a warning on both previous methods (those not taking care of "memory" HttpData part) and the new one (explaining it extends the others temporarily, until a new major version comes out) could be enough.
@normanmaurer WDYT ?

I think this cane be closed ... Please re-open if you think I am wrong