Revert "Add PooledSlicedByteBuf and PooledDuplicatedByteBuf"

[Scottmitch]

Motivation:
Currently the "derived" buffer will only ever be recycled if the release call is made on the "derived" object, and the "wrapped" buffer ends up being "fully released" (aka refcount goes to 0). From my experience this is not the common use case and thus the "derived" buffers will not be recycled.

Modifications:

• revert Add PooledSlicedByteBuf and PooledDuplicatedByteBuf #3788

Result:
Less complexity, and less code to create new objects in majority of cases."

[normanmaurer]

+1

[Scottmitch]

I will submit a followup PR to restore changes we want (reseting the indexes, etc..)

[Scottmitch]

Cherry-picked 4.0 (33001e8) 4.1 (e280251) master (77ff24b)

Each commit was a git revert for the commits listed in #3788.

[ninja-]

@Scottmitch while using netty .30 I noticed that pooledslicedbytebuf isn't recycled properly anyway (frame decoder = more gc pressure). I understand your findings that it needed this uncommon .release() usage to recycle properly.
now that I see it removed for future netty version, are you planning something related to this so it could be recycled or something? (my alternative - using a .copy() instead)

https://github.com/Scottmitch/netty/blob/a2bcd713d4db88dd19bcb14d9865aa506acf9710/buffer/src/main/java/io/netty/buffer/AbstractByteBuf.java#L934 - an object would be created every time so what was your motivation here?

Maybe I should stop playing with these buffers and just deal with a single .copy() ...

[Scottmitch]

@ninja- - .slice() and .duplicate() share the same underlying data (no copy) but just maintain different indexes over the data. copy() not only has difference indexes, but also does not share data (makes a copy). So they are different operations.

This PR fixes the complications introduced while attempting to "pool" the "derived" (slices, duplicates) taken from pooled buffers. However in most cases the pooling would never really happen and a new object would be allocated anyways because of the description of this PR.

Does that answer your question?

[ninja-]

@Scottmitch yes thanks for explaining. I am sticking with copy instead.