Add additional resets for culling state

[rreusser]

Resolves: #10372

Sky rendering may change the culling state. @astojilj pointed out that this code which ought to put WebGL in a predictable state before handing rendering off to custom layers doesn't apply consistent frontFace and cullFaceSide state, depending on whether the sky is rendered or not.

mapbox-gl-js/src/render/painter.js

Lines 756 to 758 in 63f39e5

	// The default values for this state is meaningful and often expected.
	// Leaving this state dirty could cause a lot of confusion for users.
	this.context.cullFace.setDefault();

This PR additionally resets context.frontFace and context.cullFaceSide to their defaults in context.reset(). It wasn't obvious to me how to test this, though I did check that it solves the codepen from #10372.

I'm a bit ambivalent about this change. It makes things more predictable, but it feels it risks snowballing into setting all of the WebGL state before handing off to a custom layer. Three.js has a new method called resetState() (as a result of buggy Mapbox interactions!) which fixes this problem by performing a more complete reset. I've updated the Mapbox GL-JS/Three.js example to use that function since it seems like the most robust way moving forward to minimize problems.

There are two options, I guess:

1. Merge this fix since it's still preferable to put GL in a more predictable state. This may still leave gaps in the GL state reset.
2. Omit this fix and make weaker guarantees about the state when handing off to a custom layer, putting the burden on third party libraries to enforce the state they need.

I think my preference is for 1 for this particular issue, but with an eye on this getting out of hand when third party libraries can perfectly well enforce the state they require.

cc @astojilj @karimnaaji @arindam1993 @mourner
(cc's probably not spot on; still trying to figure out how best to identify the most interested parties)

Launch Checklist

• briefly describe the changes in this PR
• include before/after visuals or gifs if this PR includes visual changes
• write tests for all new functionality
• document any changes to public APIs
• post benchmark scores
• manually test the debug page
• tagged @mapbox/map-design-team @mapbox/static-apis if this PR includes style spec API or visual changes
• tagged @mapbox/gl-native if this PR includes shader changes or needs a native port
• apply changelog label ('bug', 'feature', 'docs', etc) or use the label 'skip changelog'
• add an entry inside this element for inclusion in the mapbox-gl-js changelog: <changelog>Reset WebGL culling state before drawing custom layers</changelog>

[astojilj]

LGTM.

[karimnaaji]

That looks good, this exhausts the missing one and I don't think it is necessary to add any other states to reset here. Just to confirm, the one not defaulted here are blending, clearColor, depthTest, depthMask, depthFunc, stencilTest, stencilMask, current program & fbo.

color modes are overridden here:

mapbox-gl-js/src/render/draw_custom.js

Line 34 in ef7b2cb

context.setColorMode(painter.colorModeForRenderPass());

stencil here:

mapbox-gl-js/src/render/draw_custom.js

Line 35 in ef7b2cb

context.setStencilMode(StencilMode.disabled);

depth here:

mapbox-gl-js/src/render/draw_custom.js

Line 41 in ef7b2cb

context.setDepthMode(depthMode);

And custom layer should override the program.

[karta-solutions]

This, perhaps inadvertently, seems to have fixed an issue I was having where custom layer elements added through Three.js were simply disappearing along with a WebGL warning. Thanks for fixing that (even on accident)!

[rreusser]

@karta-solutions Solving unexpected custom layer interactions was exactly the intent! 🎉 But I'm intrigued that it resulted in a warning rather than simply undesirable/unexpected state. Do you happen to have the warning handy? Though don't bother if you don't have it handy—that it's solved is the main thing 😄

[karta-solutions]

@rreusser Yes, the error in the console read "ERROR: GL_INVALID_OPERATION: glDrawElements: range out of bounds for buffer". Not very descriptive, not sure if that helps.