Marking as Pri-1 since animations are broken 100% of the time for the bottom toolbar.

My plan for fixing this bug is to create a ToolbarContainerCoordinator that will manage holding the bottom toolbar.  Its view will be constrained to the bottom of BVC.view, and those constraints will never need to be updated.  The bottom toolbar will then be constrained to this container view, so we can call |-layoutIfNeeded| on the container view rather than BVC.view to update the positioning.

I've implemented the container view here: crrev.com/c/1208713

This is intended to be a short-term solution that's mergeable into M70; a more robust coordinator-based approach should be implemented to contain this logic.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b6ee67efd4171e9a6fab7afad9432f0c5971923c

commit b6ee67efd4171e9a6fab7afad9432f0c5971923c
Author: Kurt Horimoto <kkhorimoto@chromium.org>
Date: Tue Sep 11 03:06:33 2018

[iOS] Fix secondary toolbar animations.

The old implementation of |updateFootersForFullscreenProgress:|
just updates the height constraint for the toolbar, which isn't
actually applied to the model layer until the end of the runloop. In
order to animate this change, the model layer must be updated from
within the animation block, so |-layoutIfNeeded| is called to commit
the new constraint value to the view hierarchy.

Simply calling |-layoutIfNeeded| on the toolbar view itself will
only animate the height, not the positioning.  Since the positioning
constraint is added to BVC.view, we'd need to force a full BVC layout
to also animate the position correctly.  However, since BVC is a
heavy-weight view, and this is called for every scroll offset, calling
|-layoutIfNeeded| on BVC.view may introduce performance regressions.

This CL adds a container view for the secondary toolbar that has a
constant frame equal to that of the secondary toolbar at a fullscreen
progress of 1.0.  That way, all the constraints that need to be
animated are owned by the container and its subviews, so we can just
call |-layoutIfNeeded| on the container rather than the entire
browser view.


Bug:  880656 
Cq-Include-Trybots: luci.chromium.try:ios-simulator-cronet;luci.chromium.try:ios-simulator-full-configs
Change-Id: Ia0520d4cbfb55846efa16282e5aefae6e7f11212
Reviewed-on: https://chromium-review.googlesource.com/1208713
Commit-Queue: Kurt Horimoto <kkhorimoto@chromium.org>
Reviewed-by: Mark Cogan <marq@chromium.org>
Cr-Commit-Position: refs/heads/master@{#590182}
[modify] https://crrev.com/b6ee67efd4171e9a6fab7afad9432f0c5971923c/ios/chrome/browser/ui/browser_view_controller.mm
[modify] https://crrev.com/b6ee67efd4171e9a6fab7afad9432f0c5971923c/ios/chrome/browser/ui/toolbar/adaptive/adaptive_toolbar_view_controller.mm

Canary verification please.

Looks good in today's canary 71.0.3550.0

Your change meets the bar and is auto-approved for M70. Please go ahead and merge the CL to branch 3538 manually. Please contact milestone owner if you have questions.
Owners: benmason@(Android), kariahda@(iOS), geohsu@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ff35575ab5360e418b5a12ac0ebb6ff95de9ef8d

commit ff35575ab5360e418b5a12ac0ebb6ff95de9ef8d
Author: Kurt Horimoto <kkhorimoto@chromium.org>
Date: Wed Sep 12 17:15:34 2018

[iOS] Fix secondary toolbar animations.

The old implementation of |updateFootersForFullscreenProgress:|
just updates the height constraint for the toolbar, which isn't
actually applied to the model layer until the end of the runloop. In
order to animate this change, the model layer must be updated from
within the animation block, so |-layoutIfNeeded| is called to commit
the new constraint value to the view hierarchy.

Simply calling |-layoutIfNeeded| on the toolbar view itself will
only animate the height, not the positioning.  Since the positioning
constraint is added to BVC.view, we'd need to force a full BVC layout
to also animate the position correctly.  However, since BVC is a
heavy-weight view, and this is called for every scroll offset, calling
|-layoutIfNeeded| on BVC.view may introduce performance regressions.

This CL adds a container view for the secondary toolbar that has a
constant frame equal to that of the secondary toolbar at a fullscreen
progress of 1.0.  That way, all the constraints that need to be
animated are owned by the container and its subviews, so we can just
call |-layoutIfNeeded| on the container rather than the entire
browser view.


Bug:  880656 
Cq-Include-Trybots: luci.chromium.try:ios-simulator-cronet;luci.chromium.try:ios-simulator-full-configs
Change-Id: Ia0520d4cbfb55846efa16282e5aefae6e7f11212
Reviewed-on: https://chromium-review.googlesource.com/1208713
Commit-Queue: Kurt Horimoto <kkhorimoto@chromium.org>
Reviewed-by: Mark Cogan <marq@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#590182}(cherry picked from commit b6ee67efd4171e9a6fab7afad9432f0c5971923c)
Reviewed-on: https://chromium-review.googlesource.com/1222189
Reviewed-by: Kurt Horimoto <kkhorimoto@chromium.org>
Cr-Commit-Position: refs/branch-heads/3538@{#333}
Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811}
[modify] https://crrev.com/ff35575ab5360e418b5a12ac0ebb6ff95de9ef8d/ios/chrome/browser/ui/browser_view_controller.mm
[modify] https://crrev.com/ff35575ab5360e418b5a12ac0ebb6ff95de9ef8d/ios/chrome/browser/ui/toolbar/adaptive/adaptive_toolbar_view_controller.mm