Resolve Layout changes during native measure/arrange pass

[hartez]

Description of Change

To avoid excessive re-layouts, any property changes which trigger a layout in a Forms Layout (StackLayout, FlexLayout, etc.) are currently batched up and executed later on the UI thread. While this avoids "layout storms", it also introduces a slight delay in layout changes in the UI and in some rare cases can cause consistency issues. It also means that for many UI changes the native layout engine ends up being invoked an extra time to handle the queued layout changes.

These changes handle the queued layout changes as part of the next measure/layout pass of the native engine on the supported platforms (UWP, iOS, and Android) rather than queueing them up on the UI thread for later processing. This reduces the number of measure/layout passes on those platforms, and eliminates some of the potential consistency issues.

These changes also retain support for the old behavior on platforms which have not added layout resolution to their measure/layout process. Other platforms can opt into the new behavior by implementing the IPlatformInvalidate interface and setting the PlatformInvalidator property on the Device class during Forms.Init.

Issues Resolved

Delays and extra measure/layout passes on the supported platforms.

API Changes

New interface:

interface IPlatformInvalidate {
    void Invalidate(VisualElement element);
}

Platforms Affected

• Core/XAML (all platforms)
• iOS
• Android
• UWP

Behavioral/Visual Changes

None

Before/After Screenshots

Not applicable

Testing Procedure

All the tests.

PR Checklist

• Targets the correct branch
• Tests are passing (or failures are unrelated)

[rmarinho]

Issue 45125 failing on Android all API's i think might be related

[hartez]

None of these UI test failures have anything to do with the changes.
@rmarinho Need another review.

[hartez]

Issue 45125 failing on Android all API's i think might be related

That one's fixed.