Avoid setting scrollbar enabled state after style

This is a small cleanup.

The code here was added way back in https://crrev.com/ba35627328434 as
part of https://bugs.webkit.org/show_bug.cgi?id=11985.

Today, scrollbar enabled state is computed explicitly in
UpdateScrollbarEnabledState. I believe this is no longer needed, to see
why:

- This will only make a difference if the scrollbars were disabled prior
  to reaching this method.
- If the scrollbars were disabled and were overflow:scroll, this means
  they didn't have overflow
- If overflow was added at the same time as the style changed, we'll do
  a layout and update enabled state in UpdateAfterLayout or
  UpdateAfterOverflowRecalc
- Otherwise, the scrollbars will be removed as there's no overflow and
  we're in overflow:auto|visible|hidden.

Bug: None
Change-Id: Iabc37c6933f43726529fb7fb19436393c53a5014
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2123635Reviewed-by: Stefan Zager <szager@chromium.org>
Commit-Queue: David Bokan <bokan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#754128}

third_party/blink/renderer/core/paint/paint_layer_scrollable_area.cc

@@ -1327,20 +1327,6 @@ void PaintLayerScrollableArea::UpdateAfterStyleChange(
         LayoutBlock::ScrollbarChangeContext::kStyleChange);
   }
 
-  // With overflow: scroll, scrollbars are always visible but may be disabled.
-  // When switching to another value, we need to re-enable them (see bug 11985).
-  if (HasHorizontalScrollbar() && old_style &&
-      old_style->OverflowX() == EOverflow::kScroll &&
-      GetLayoutBox()->StyleRef().OverflowX() != EOverflow::kScroll) {
-    HorizontalScrollbar()->SetEnabled(true);
-  }
-
-  if (HasVerticalScrollbar() && old_style &&
-      old_style->OverflowY() == EOverflow::kScroll &&
-      GetLayoutBox()->StyleRef().OverflowY() != EOverflow::kScroll) {
-    VerticalScrollbar()->SetEnabled(true);
-  }
-
   // FIXME: Need to detect a swap from custom to native scrollbars (and vice
   // versa).
   if (HorizontalScrollbar())