core: reduce CompositeReadableBuffer allocation

[Gordiychuk]

Add ability for CompositeReadableBuffer read specified length bytes
to another CompositeReadableBuffer instead of create temp
CompositeReadableBuffer.

Allocation before changes:

Allocation after changes:

Close: #3278

[grpc-kokoro]

Thanks for your pull request. The automated tests will run as soon as one of the admins verifies this change is ok for us to run on our infrastructure.

[Gordiychuk]

Now in allocation top netty netty/netty#7026

[ejona86]

I'm fine with these changes, but I'd like @carl-mastrangelo to review.

[carl-mastrangelo]

I suspect this may hurt streaming RPCs, though unary seems to pass.

@Gordiychuk Would you mind looking at a previous PR that modifies this file in a different way: #2092

[ejona86]

@carl-mastrangelo, what do we want to do here? The change seemed fair to me and seems to be a easy way to reduce garbage. Was your concern just the new ArrayDeque<ReadableBuffer>(2)? I do agree that the default of 16 is probably a bit much, maybe you'd be happy with 4? Worst-case, maybe we revert that part of the change but apply the other changes?

[thelinuxfoundation]

Thank you for your pull request. Before we can look at your contribution, we need to ensure all contributors are covered by a Contributor License Agreement.

After the following items are addressed, please respond with a new comment here, and the automated system will re-verify.

• User @Gordiychuk isn't covered by a CLA. They will need to complete the form at https://identity.linuxfoundation.org/projects/cncf

Regards,
CLA GitHub bot

[carl-mastrangelo]

LGTM, (assuming it can merge)

[zhangkun83]

@ejona86 @carl-mastrangelo ping

[carl-mastrangelo]

LGTM

[dapengzhang0]

@Gordiychuk Would you please sign the CLA (otherwise we can't merge) and then resolve the merge conflicts?

[Gordiychuk]

I signed it

[sanjaypujare]

This PR was approved but now needs to be rebased after resolving conflicts and also needs the new CLA. Otherwise it should be closed I think.

[georgelee1]

Hey @Gordiychuk, any plans to rebase soon to get this in, keen to see this get merged. If not I'm happy to create a new PR with these changes based on master. Let me know, thanks.

[ejona86]

Note: #7375 might have partly addressed the same allocation. But the solution here is simpler and more predictable, so we could have both.