Adds support for arbitrary raster dem max zoom levels

[ibesora]

Launch Checklist

• briefly describe the changes in this PR
  When the hillshade_prepare shader computes the exaggeration factor, a max zoom level of 14 is assumed. We have a raster dem pyramid generated from our own data that goes to level 16 so when the exaggeration factor is computed in levels 15 and 16, giving a result bigger than 1, the hillshade is scaled down.
  This PR sends the source-defined max zoom level to the shader so the exaggeration factor can be correctly computed.
• manually test the debug page
  The mapbox.terrain-rgb style JSON defines a max zoom level of 15.
  
  At level 15 and higher, the zoom uniform is bigger than 14 so, when computing the exaggeration factor, the slope is instead dimmed. With this modification, computing the exaggeration factor with a max zoom value of 15, increases the darkness of the hillshade at levels >= 15.
  You can see the difference in this gif.
  
  With our dem pyramid the hillshade is not dimmed when on levels bigger than 14.

@mollymerp Does this sound good to you? I have run all the tests and works as expected.

[ibesora]

Now I see that some tests (all combinations with hillshade-translucent) fail on your CI. Running these tests locally passes all of them. I suppose that could be tied with the difference in brightness with and without this modification but then, I don't understand how it works in my computer.

[mollymerp]

thanks @ibesora – I mistakenly thought that the maxzoom for terrain-rgb was 14 but it is actually 15. I'm not sure we need to add a new uniform, however, because both mapbox and mapzen terrain rgb sources only go up to Z15 – are you thinking of the case where a user would generate their own tileset?

@nickidlugash can you take a look at this change from the carto perspective?

[ibesora]

Yup, as I said, in the national mapping agency where I work we have a very detailed DEM, encoded in Mapbox terrain RGB and Mapzen's Terrarium formats, that can go to level 18.
The detail is amazing and it would really be a loss if we couldn't visualize it.

If the cost of setting the uniform is too much, seeing that the max zoom level of a layer doesn't change, could a shader define be set when the shader is compiled?

[mollymerp]

ah yep sorry I didn't read the OP closely enough 😳 – I'm ok with adding the uniform if it will be useful to users 👍

to fix the test you'll need to run UPDATE=true yarn test-render hillshade and commit the new expected.png files, but yeah I'm not sure why they'd be passing locally for you.

[ibesora]

I've just generated and pushed the expected images.
Thanks for the work @mollymerp, the hillshade looks amazing! 👏

[nickidlugash]

@nickidlugash can you take a look at this change from the carto perspective?

@mollymerp @ibesora sorry for the delay – I think this PR makes sense and looks good 👍 Since it makes the hillshading slightly more exaggerated at all zoom levels (compared to the implementation in master), I reviewed the hillshading display with a variety of values for hillshade-exaggeration. I initially wasn't sure if we would need to adjust any of the arbitrary constants in the hillshade.fragment shader to account for this change, but I think the display looks fine without further changes.

[mollymerp]

this looks good to me @ibesora – I merged a change to hillshade rendering in #6059 that is making the test images conflict. I will rebase and merge this in on the command line.

thanks again for the contribution!!

[mollymerp]

merged as #6103