Fixes #6591

It wasn't taking padding into account when deciding which children were
visible. I modeled the solution off of the way ScrollableList handles
this.

Fixes https://github.com/flutter/flutter/issues/5522

See #4434.

This patch exposes a convenience function on Scrollable that helps with
updating the scroll extents and ports several clients over to using it.

This required refactoring some cases where we weren't following the rules for
the protected annotation.

* ScrollableBuilder tweaks

* Add a Scrollable builder, refactor ScrollableList, et al

* Add space between the dialog demo buttons

* removed vestigial code

This patch adds dartdoc to LazyBlock. Also, this patch fixes the scrolling
physics of LazyBlock. Previously, we updated a running simulation only when the
change in scroll behavior changed the current scroll offset. Now we update
running simulations every time the behavior changes because the simulation
might depend on quantities other than the current scroll offset.

LazyBlock is intended as a replacement for MixedViewport. Rather than

maintaining a table of all the observed child sizes (like

MixedViewport), LazyBlock works by dead reckoning the location of the

children based on the existing viewport. This approach makes it easier

to resize children because LazyBlock doesn't cache any additional

information that would need to be invalidated.



This patch contains a first draft of LazyBlock that works in a simple

usage scenario. Subsequent patches will replace

ScrollableMixedWidgetList with LazyBlock and port the existing

ScrollableMixedWidgetList tests over to LazyBlock.



Related to #3075

Previously, when the content extent changed during a scroll interaction, we'd
stop the current scroll interaction and reset the scroll offset. Now we try to
continue the scroll interaction (e.g., drag, fling, or overscroll) even through
the underlying scroll behavior has changed.

For physics-based scroll interactions, we keep the current position and
velocity and recompute the operative forces. For drag interactions, we keep the
current position and continue to let the user drag the scroll offset.

After this patch, we still disrupt non-physical scroll animations that are
operating outside the new scroll bounds because it's not clear how we can
sensibly modify them to work with the new scroll bounds.

Fixes #581

And fix the zillion issues that uncovered.

This reverts commit f41b3411, reversing
changes made to e33d8d96.

This was a bad check-in due to my mangling uploading a new version of the branch from a different machine.

This reverts https://github.com/flutter/flutter/pull/2639 and will be replaced by https://github.com/flutter/flutter/pull/2640

And fix the zillion issues that uncovered.

We'll need this for RTL support because the RTL state will live in the widget
tree. Also, remove the `oldWidget` argument to updateRenderObject because there
aren't any clients for it.

Remove the SizeObserver you need to use snap alignment in lists by
having the lists provide the size themselves in the callback.

Also, remove snapAlignmentOffset since we couldn't figure out how to
explain it and it's not really needed.

The virtual viewport machinery now handles all of these use cases.
Previous clients of ScrollableWidgetList can use ScrollableLazyList
instead.

Previously this code was in the animation layer, which didn't make much
sense because scrolling is a widget concern.

We were recomputing which widgets to show only when we were on the other side
of the repaint boundaries. That doesn't work well for pageable lists because we
come to rest exactly on a repaint boundary, which means we don't cull the other
page.

After this patch, we recompute the set of widgets using an edge-trigger when we
hit the boundary. That's better than using a level-trigger so that we don't
continuously recompute the set of widget as we sit at the boundary.

We use the ScrollDirection for more than just scrolling.

Fixes #151

This patch moves PageableList off HomogeneousViewport and onto RenderList and
friends, making it match the new ScrollableList.

When paging a scrollable list, we were trying to read the render object's size
at a time when we're not allowed to read it. Instead, encode the information
into the repaint limit, which is more correct (and faster) anyway.

This patch also changed ScrollableList2 to use an Iterable instead of an
List for its children. This change lets clients map their underlying
data lazily. If the clients actually have a concrete list, we skip the
extra copy and grab the child list directly.

This patch implements the remaining missing features of ScrollableList2.
It should now be nearly a drop-in replacement for ScrollableList. The
next patch will switch callers over to the new machinery.

ScrollableList2 uses the same pattern as ScrollableGrid, which requires the
client to allocate widgets for every list item but doesn't inflate them unless
they're actually needed for the view. It improves on the original
ScrollableList by not requiring a rebuild of the whole visible portion of the
list when scrolling. In fact, small scrolls can often be handled entirely by
repainting.

We now support (vertically) scrollable grids with viewporting. If the
scroll doesn't reveal any new rows, we execute the scroll with a repaint
(i.e., no layout). If the scroll reveals a new row, we trigger a layout
to change the set of materialized children in the viewport.