Correct the frame timing in 'Rasterizer::Draw' when pipeline is more available

[ColdPaleLight]

The current implementation always uses resubmit_recorder as the frame_timings_recorder for the next Rasterizer::Draw when consume_result is PipelineConsumeResult::MoreAvailable. However, in fact, we should use resubmit_recorder only when should_resubmit_frame is true, and for other cases, we should use the frame_timing_recorder corresponding to the next item in the pipeline.

In this PR, I introduced a new struct LayerTreeItem to store layer_tree and frame_timings_recorder, and push the LayerTreeItem into Pipeline. This ensures that the correct frame_timings_recorder is used in Rasterizer::Draw;

fix flutter/flutter#96699

c.f.

engine/shell/common/rasterizer.cc

Line 226 in 98962ee

resubmit_recorder = std::move(resubmit_recorder),

Pre-launch Checklist

• I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
• I read the [Tree Hygiene] wiki page, which explains my responsibilities.
• I read and followed the [Flutter Style Guide] and the [C++, Objective-C, Java style guides].
• I listed at least one issue that this PR fixes in the description above.
• I added new tests to check the change I am making or feature I am adding, or Hixie said the PR is test-exempt. See [testing the engine] for instructions on
  writing and running engine tests.
• I updated/added relevant documentation (doc comments with ///).
• I signed the [CLA].
• All existing and new tests are passing.

[ColdPaleLight]

Since frame_timings_recorder is in the pipeline, it can't be accessed here. So I changed the code here back to before this PR #26205 and added a trace in DoDraw. It looks like this will have an impact on the dev tools. Please let me know if you guys have any thoughts.

[iskakaushik]

This might impact the devtools, as it looks for specific frame number events corresponding to ::Draw. @kenzieschmoll do we still rely on the names of trace events or do we only care about the frame timings API?

[kenzieschmoll]

We look for the 'frame_number' arg in the 'GPURasterizer::Draw' trace event and the 'Animator::BeginFrame' trace event to link timeline events to their matching frame number from the FrameTimings API. If this change removes the 'frame_number' argument, this will break DevTools. However, if it just moves the argument to a different event, we can update the event name we look for to include both the legacy name and the new name.

[iskakaushik]

I filed https://github.com/flutter/flutter/issues/105140, once that is addressed, we can land this PR.

[kenzieschmoll]

Addressed here: flutter/devtools#4156

[zanderso]

From PR review triage: @chinmaygarde @iskakaushik is this ready for a review?

[chinmaygarde]

I don't have the cycles to review this ATM. I'll bring this up with Kaushik.

[ColdPaleLight]

friendly ping @iskakaushik

[iskakaushik]

This change looks good to me overall, I will wait for Kenzie's response on this reg. devtools.

[zanderso]

I see the devtools change has landed. Is this one ready to go?

[iskakaushik]

LGTM

[iskakaushik]

@ColdPaleLight thanks for the contribution.