fix(gatsby-plugin-image): Correct IntersectionObserver handling

[ascorbic]

It turns out that the intersectionobserver never worked proeprly, but our tests didn't catch it because it works for the first image but not subsequent ones, and aside from Safari the images were all loading immediately when they were inside the intersection threshold. The problem was that we were using a shared IO instance (which is fine), but the IO's event listener was only calling the callback of the element that originally created it, and not any that were subsequently observed. This fixes it by using a WeakMap to map the image DOM element to its callback.

This also fixes the intersection thresholds, which were an arbitrary 150%. They now match the values used by Chrome native lazy loading, which vary according to the connection speed (where available).

[wardpeet]

Nice! Could you add an e2e test so we don't have any regressions in the future?

[mfrachet]

@wardpeet this is exactly why we actually have our conversation about devtools and Cypress 😊 : I'm writing them

[wardpeet]

E2e test can be in a follow up, no need to block this PR for it

[ascorbic]

Marvin's a machine, and they're already in. I've just asked if he can move them to a different suite, but otherwise they look great to me

[mfrachet]

I think we are still testing the intersection observer here. I'm always hitting https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby-plugin-image/src/components/gatsby-image.browser.tsx#L111 because hasSSRis not defined in https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby-plugin-image/src/components/gatsby-image.browser.tsx#L94

[ascorbic]

@mfrachet It'll hit that if you're running gatsby develop, but these tests run gatsby build/serve, so they will have hasSSR set