Executing useBreakpoints isormophically no longer triggers a Hydration mismatch error or rendering bugs.

[jesstelford]

To reproduce:

1. Visit https://polaris.shopify.com/examples/card-with-rounded-corners which should show rounded corners from 768px viewport width and above.
2. Set your viewport width to 768px or more (ie; so it matches md breakpoint or more)
3. Refresh the page
4. Notice there are no rounded corners
5. Resize your viewport to be 767px or less.
6. Resize your viewport to be 768px or more.
7. Notice the rounded corners now appear.

Before

This PR

---

More details

This is an issue anywhere useBreakpoints() is used with SSR.

For example, with <Banner>;

1. Style props are being set based on a variable smUp: https://github.com/Shopify/polaris/blob/next/polaris-react/src/components/Banner/Banner.tsx#L202-L205
2. smUp is defined above as const {smUp} = useBreakpoints();
3. In SSR, useBreakpionts initially returns a call to getMatches(), forwarding any "default" parameters (none are passed in by <Banner>)
4. In SSR, getMatches() returns false for all breakpoints unless a default is set
5. Back in useBreakpoints(), an effect is used to setup media query match event listeners. These trigger each time the matchy-ness of a media query changes, but not in between.
   • For example, between sm (>490px) to md (<768px), the matchy-ness of the media queries are not changing, so none of the event listeners will be called. But once the window hits 768px, md will now match, and so the event listener is triggered which updates state and re-renders the component.
   • Note also that when doing SSR, the initial values of the getMatches() calls will differ client-side than server-side, resulting in a "Hydration error", but critically will not re-render with the client-side values.
6. So the end result; smUp === false in SSR, then is immediately smUp === true in CSR causing a client side "Hydration error", but continues to render with the SSR values until the window is resized past a breakpoint triggering a state update to reflect the new breakpoint.

[gwyneplaine]

lgtm

[jesstelford]

The useEffect inside of useBreakpoints will cause this component to render twice during mount, so we assert the initial and subsequent values are what we expect.

[jesstelford]

Moving the assertions after the mount call (instead of inside it) gives useBreakpoint's useEffect a chance to run, so we're asserting against the final values, not the SSR defaults.