Parameterize Geoprocessing Rasters

[rajadain]

Overview

Previously, the raster layer names were hardcoded in specific JSON blocks of configuration. Now, since we may use a variant for different types of raster layers (land, soil, etc), we parameterize the configuration, replacing a token with the real layer name at run time.

There is a default set of layers that will be used if no overrides are provided. Only those layers that are being overridden need to be provided, the rest will come from the default.

When using the default layers, the existing cache keys will be used. When using overridden layers, those layer names will be added to the cache key. If the default layers are ever changed, we'll have to clear the geoprocessing cache. This PR only tokenizes the layers, and does not change the default ones.

This will mainly be used for MapShed modeling, but we also refactor Land analysis to use this, which cuts down on lines of code and demos the feature.

Connects #3405

Testing Instructions

• Check out this branch
• Delete all cached geoprocessing runs:

  $ vagrant ssh services -c 'redis-cli -n 1 --raw KEYS ":1:geop_*" | xargs redis-cli -n 1 DEL'

  This is necessary whenever we change the default layers. Not the case in this PR, but might as well.
• Restart celery:

  $ vagrant ssh worker -c 'sudo service celeryd restart'

• Go to :8000 and find a shape that has variation between 2001 and 2019 land covers. Or just type in "Van Sciver Lake" into the search box in the top right, and select the "Van Sciver Lake-Delaware River, HUC-12 Subwatershed" shape (it may take a while to show up, wait for the spinner to end)
• In the Land Analysis, ensure that the 2001 and 2019 have different results in the chart and table (compare the value of Deciduous Forest if using Van Sciver Lake), and compare with the same shape on https://staging.modelmywatershed.org/ to confirm

[rajadain]

There's a failing test, taking a look at it now

not ok 118 Firefox 88.0 - [1008 ms] - Modeling Models ScenarioModel #fetchResults sets results to null on polling failure
    ---
        message: >
            uncaught exception: AssertionError: attemptSave should have been called twice (http://localhost:7357/333799856769/js/test.vendor.js:22067)
        browser log: |
            LOG: Failed to get modeling results.
            LOG: Completed polling for modeling results
    ...

[rajadain]

It was a seemingly transient failure. Am not seeing that test fail on my local, and it now it passes on CI as well.

[jwalgran]

I was able to run through the testing steps and see the same changes between 2001 and 2019 on both staging and this branch. I left a few comments not related to the functionality.

[rajadain]

Thanks for all the great suggestions! They have all been recorded in future issues or addressed herein. Going to merge this now so it's ready for demo tomorrow, especially since the last commit is only documentation changes.