[Tracking] backporting current http2 to v8.x

[jasnell]

The current http2 implementation in master and v9 build on a number of major PRs that have not yet been landed in v8.x, making it impossible/non-trivial to backport. We can use this issue to coordinate.

• Backport AliasedBuffer - http2, async-wrap: introduce AliasedBuffer class #15077 (and subsequent related PRs)
• Backport Environment::SetImmediate() - src: introduce internal C++ SetImmediate() and remove async_hooks destroy timer #17117 and subsequent related PRs)
• Backport set of http/2 PRs
• Backport current perf_hooks impl

/cc @nodejs/http2 @addaleax @mcollina @mike-kaufman @MylesBorins

[mcollina]

Are all of these interanls strictly needed? Can we skip them? I hope we can avoid perf_hooks.

I think we should backport

a) the new destroy flow
b) ref/unref
c) the DoS protections
d) the new read flow

[jasnell]

Yes, both aliasedbuffer and the internal Set immediate are required. The perf hooks stuff is trivial and not on the critical path.

[mike-kaufman]

happy to help, but not sure precisely what I need to do. :) Is this just cherry-picking into another branch?

[jasnell]

@mike-kaufman ... hopefully that's all that would be required but potentially some tweaks here and there... and definitely don't feel obligated, by any means. I mentioned you since you were the author of the AliasedBuffer code and would know the most about it. :-)

[Tiriel]

I'd like to help on this one if it's ok.
I'd like to get my hands on something of a better level than the console things I did.

Is there any item I might start with?

[mike-kaufman]

@jasnell, @mcollina - is there an approach here that you guys have used in the past for things like this?

In lieu of someone coming up w/ something easier/better, I propose the following things need to happen

1. Identify the specific commits to cherry-pick (some are listed above but not all)
2. Identify the order in which these commits should be cherry-picked
3. Identify a staging branch to land the cherry-picks, someplace "unstable" where people can collaborate on any necessary conflict resolutions/fix-ups.

LMK if this sounds right & we can add to list above?

@Tiriel - I'm assuming that once we agree on plan/approach, you can start picking grabbing things off that list.

[mike-kaufman]

Here are specific commits from the aliased buffer change:

35a526c1
6faede7e

[jasnell]

@mike-kaufman ... if you haven't done so already, I recommend starting here: https://github.com/nodejs/node/blob/master/doc/guides/backporting-to-release-lines.md

The process you describe is broadly correct. In this case, create new working branch off v8.x-staging and first attempt to cherry-pick the necessary commits in. As conflicts are found, see if those can be resolved and modify the cherry-picked commits accordingly. Once your set of backported commits is ready to go, open a new PR targeted at v8.x-staging