This lets us control the paint order between the slivers, so that
the top sliver is able to overflow over the bottom sliver when a
sticky header calls for that.

I've sent a PR upstream to add the same feature to CustomScrollView
itself:
  flutter/flutter#164818

That PR has been delayed by infra issues in Google testing, though.
So doing this in our tree lets us move ahead without waiting.

(I actually wrote this version first, then adapted it to produce the
upstream PR.  So landing this version isn't significant extra work.)

This lets us control the paint order between the slivers, so that
the top sliver is able to overflow over the bottom sliver when a
sticky header calls for that.

I've sent a PR upstream to add the same feature to CustomScrollView
itself:
  flutter/flutter#164818

That PR has been delayed by infra issues in Google testing, though.
So doing this in our tree lets us move ahead without waiting.

(I actually wrote this version first, then adapted it to produce the
upstream PR.  So landing this version isn't significant extra work.)

These two tests on CustomPaintOrderScrollView compare its behavior
to the default z-order / paint order behavior of CustomScrollView.
They'd therefore be broken by my upstream PR that gives
CustomScrollView the functionality of CustomPaintOrderScrollView
and simplifies its default behavior:
  flutter/flutter#164818

So skip the tests.  Once that PR lands, we can update past it and
then remove CustomPaintOrderScrollView and its tests entirely.

(The customer_tests failures currently seen on the upstream PR are
different, because the Zulip pin in flutter/tests is currently at
d302584.  The failures there are in the sticky_header tests, which
want to exercise a variety of sliver configurations and need to
control the z-order when they do so.  As of d302584, they did so
by relying on the specifics of the existing CustomScrollView
behavior.  Since then we merged CustomPaintOrderScrollView, and in
49eff8b adapted those tests to use it, making them immune to
changes in the default z-order; but that also meant adding
CustomPaintOrderScrollView's own tests, including these two.)

These two tests on CustomPaintOrderScrollView compare its behavior
to the default z-order / paint order behavior of CustomScrollView.
They'd therefore be broken by my upstream PR that gives
CustomScrollView the functionality of CustomPaintOrderScrollView
and simplifies its default behavior:
  flutter/flutter#164818

So skip the tests.  Once that PR lands, we can update past it and
then remove CustomPaintOrderScrollView and its tests entirely.

(The customer_tests failures currently seen on the upstream PR are
different, because the Zulip pin in flutter/tests is currently at
d302584.  The failures there are in the sticky_header tests, which
want to exercise a variety of sliver configurations and need to
control the z-order when they do so.  As of d302584, they did so
by relying on the specifics of the existing CustomScrollView
behavior.  Since then we merged CustomPaintOrderScrollView, and in
49eff8b adapted those tests to use it, making them immune to
changes in the default z-order; but that also meant adding
CustomPaintOrderScrollView's own tests, including these two.)

This updates to the following change in Zulip:
  zulip/zulip-flutter#1480
  zulip/zulip-flutter@88e7bcc

in order to unblock this PR:
  flutter/flutter#164818

This updates to the following change in Zulip:
  zulip/zulip-flutter#1480
  zulip/zulip-flutter@88e7bcc

in order to unblock this PR:
  flutter/flutter#164818

> [!IMPORTANT]
> This repository is a testing suite that contains references to tests (in the `registry` directory) that are run with every commit to Flutter
> to verify that no breaking changes have been introduced (in the "customer_testing" shards). Your merged PR is _not_ automatically run in the
> Flutter CI tree.
>
> After merging this PR, you must send another PR to flutter/flutter updating `dev/customer_testing/tests.version` in that repo with the latest git commit SHA of the flutter/test repo.
>
> See <flutter/flutter#162048> for details.

…64818)

…64818)

…64818)

…64818)

…64818)

…64818)

…64818)

…64818)

…64818)

…64818)

…64818)

…64818)

…64818)

…64818)

…64818)

…64818)

…64818)

…64818)

…64818)

…64818)

…64818)

…64818)

…64818)

…64818)

…64818)

Fixes flutter#145592.

When slivers in a CustomScrollView overlap, this makes it possible to
control which of the slivers will sit in front of the other one, meaning
that it paints last and gets hit-tested first.

In this version there are two choices: the first sliver paints in front,
or the last sliver paints in front. The first sliver in front is the
default; it's the behavior needed for SliverAppBar, or other situations
where the first sliver is some sort of header.

The existing behavior is actually quite a bit more complicated than
that, with the "center" sliver painting in front, plus it varies
depending on `shrinkWrap`. As far as I can tell this behavior isn't
documented anywhere. It's equivalent to first-sliver-in-front whenever
`CustomScrollView.center` isn't being used; and in fact there don't seem
to be any tests in the tree that notice the difference between the
existing behavior and first-sliver-in-front.

So although I actually have an implementation that preserves the more
complex existing defaults, I'm hopeful we won't need it: if neither
google3 nor customer tests are relying on that undocumented distinction
either, then we can go ahead and simplify this behavior without a
breaking change.

…64818)

…64818)

…64818)