Exclude modifications for regional analysis lookup

[trevorgerhardt]

This change adds a new helper method to pass a fields object to MongoMap#findByIdIfPermitted and utilizes that to exclude modifications while looking up a regional analysis to generate a scenarioJsonUrl.

This will prevent JacksonDBDecoder errors from occurring if custom modifications are used in a worker version that do not also exist in the server. Sample errors like:

java.lang.RuntimeException: IOException encountered while reading from a byte array input stream
at org.mongojack.internal.stream.JacksonDBDecoder.decode(JacksonDBDecoder.java:67)
at com.conveyal.analysis.persistence.MongoMap.findByIdIfPermitted(MongoMap.java:51)

[abyrd]

Reviewed together with @ansoncfit at the Thursday meeting. We talked through the underlying problem.

• Backend should be able to deserialize unknown types without blowing up (into CustomModificationHolder).
• Arguably these should be written into the database as type=custom as the original intent was to only ever deserialize custom modifications in a typed fashion on workers.
• Considered whether it is necessary to save this scenario detail into the database at all if we’re always providing it by fetching this JSON file.
• Read through Regional analysis persistence cleanup #621 recalling that we have long discussed representing the scenario modifications in persistent storage with the UI types instead of the R5 types, to better decouple them from worker versions.
• Noted that this PR specifically eliminates the Scenario, while in fact the API endpoint only needs two fields from the entire regional analysis object. So a more basic way to circumvent the problem is to request only the two fields actually needed from the database. However the database wrapper available here focuses solely on fetching into typed objects, probably making that awkward.

Considering all of the above, we decided to go ahead with the approach in this PR, and will create or update an issue to capture the various observations for future reference.

[abyrd]

I just tried out replacing DBProjection.exclude("request.scenario.modifications") with DBProjection.include("bundleId", "scenarioId", "accessGroup" to grab only the fields necessary to return the API response. This does work... almost. But the field regionalAnalysis.request.scenarioId is different than regionalAnalysis.scenarioId in the baseline scenario case (UUID versus the string "baseline" respectively). Fetching regionalAnalysis.request.scenarioId means fetching regionalAnalysis.request which runs into other problems with type fields and quickly becomes more trouble than it's worth. The other underlying problem to note here is that we have multiple ways to reference the baseline scenario as a string and mix them together in a single object.