fix: Handle geojson features that cross antimeridian in computeBbox

[camdecoster]

Description

Update computeBbox to handle geojson features that cross the antimeridian.

Closes #4436.

Changes

• Use d3-geo to get coords for features that cross the antimeridian instead of turn/bbox
• Update computeBbox call sites
• Add/update tests

Testing

• Be on master
• Load Plotly devtools
• Paste the following snippet into the browser devtools console

  Plotly.newPlot(gd, [{
      type: 'choropleth',
      locations: ['RUS'],
      z: [1],
      colorscale: [[0, '#c33'], [1, '#c33']],
      showscale: false
  }], {
      geo: { fitbounds: 'locations', projection: { type: 'equirectangular' } },
      width: 700,
      height: 500,
      margin: { l: 0, r: 0, t: 0, b: 0 }
  });

• Note that the plot spans the whole world
• Switch to this branch
• Run the snippet again
• Note that the plot spans only Asia

Screenshots

Before	After

Notes

• This has been a long-standing TODO (from 2019)
• @turf/bbox doesn't handle geometry that spans the antimeridian and there's been no movement to fix that issue
• This update uses a D3 utility (d3-geo.geoBounds, that does work with the antimeridian) to do the same thing (along with a turf utility used within @turf/bbox)
• This could be considered a breaking change as some plots will show something different for the same config

[emilykl]

Can you expand this docstring to clarify the numeric range of each coordinate, and any constraints on the output, and also whether east is guaranteed to exceed 180 if the input crosses the antimeridian?

[camdecoster]

I'll add a bit more info, but some of what you're asking for seems out of scope of a docstring.

[emilykl]

I don't know what CW exterior or geodesic apex overshoot mean, could you tweak this comment to be a bit more readable?

[camdecoster]

Yeah, that's confusing. I'll simplify it.

[emilykl]

Can use unwrapLonRange() here now that #7881 is merged, right?

[camdecoster]

This check is slightly different, but I can probably get everything to use the same calc. I'll update it.

[emilykl]

I realize this issue predates your changes, but it seems a little silly to compute bounding boxes for all the features here if they might be ignored in the next step. Maybe a small refactor would make sense?

It's beyond the scope of this PR though so not necessary.

[camdecoster]

Good idea! That does seem a bit wasteful. Let me poke at it.

[emilykl]

Is it worth adding a similar test here for choropleth to verify the changes end-to-end? And/or an image test? (I'm a little surprised that none of the existing image baselines changed as a result of these changes, but I guess it requires a pretty specific combination of factors to surface this issue.)

[camdecoster]

In the follow up work to default to fitbounds = "locations", I'll address adding tests. This one just needed to be updated because of computeBbox changed.

[emilykl]

Left some nitpick comments, but LGTM.