Fix abrupt jump with globe view + maxBounds after transition to mercator

[mourner]

Quick follow-up to #12114. Make sure the constraining logic is the same throughout the zoom range for the globe view so that there are no abrupt jumps when zooming in. We don't have to be very precise here because it doesn't make sense to use maxBounds on higher zoom levels coupled with the globe view anyway (the advantage of the latter disappears).

Launch Checklist

• briefly describe the changes in this PR
• write tests for all new functionality
• manually test the debug page
• apply changelog label ('bug', 'feature', 'docs', etc) or use the label 'skip changelog'

[karimnaaji]

One thing to note is that we trade the jump for slightly different behaviors when switching between mercator/globe:

• Here are the constraints with globe (correctly constraining map center), the bounds are represented by the markers:

globe.mov

• And here with a switch back to mercator, constraining center and then viewport after a switch of projection:

globe-mercator-transition.mov

Overall, it seems preferable to introduce this fix to prevent abrupt jumps during the transition; projection switches are typically less frequent compared to crossing the transition, but this could still be confusing from a user perspective.

I'm in favor of merging but could we have a small note about the differences in the documentation? e.g. when using an explicit globe or alternate projection, we constrain only map center vs viewport otherwise, I don't believe we have a mention of that yet and seem to only refer to pan/zoom as constraints https://docs.mapbox.com/mapbox-gl-js/api/map/#map#setmaxbounds

Pan and zoom operations are constrained within these bounds. If a pan or zoom is performed that would display regions outside these bounds, the map will instead display a position and zoom level as close as possible to the operation's request while still remaining within the bounds.

Otherwise, I wonder if Mercator would benefit from adopting the same logic as well by constraining the map center instead. Even though that would be a breaking change, the current viewport constraints only really work in 2d top-down views. When starting to pitch, we can easily cross these bounds on the viewport and the constraints aren't honored. I'm not sure if that was a deliberate decision or if the addition of pitch and bearing didn't fully consider this API when first introduced.

[mourner]

Added a small note to setMaxBounds docs.

I'm not sure if that was a deliberate decision or if the addition of pitch and bearing didn't fully consider this API when first introduced.

I think we never reconsidered maxBounds behavior after pitch was introduced. I think the intent of the original behavior was to avoid empty stripes on top/bottom when zooming out an ordinary map, so that it always covers the view. Not sure whether we should change the default behavior now — either has tradeoffs, but we could explore this in a separate issue.