Optional map snapshotter camera position

[tobrun]

When looking into render differences from android render tests, I was noticing the following behavior:

expected	actual	output

With using the following style.json:

{
  "version": 8,
  "metadata": {
    "test": {
      "width": 64,
      "height": 64
    }
  },
  "bearing": 45,
  "sources": {},
  "sprite": "local://sprites/emerald",
  "layers": [
    {
      "id": "background",
      "type": "background",
      "paint": {
        "background-pattern": "cemetery_icon"
      }
    }
  ]
}

Was able to track down that our camera definition in the style.json was overwritten by the default camera:

     if (style.first) {	  
         map.getStyle().loadJSON(style.second);	         
     } else{	  
         map.getStyle().loadURL(style.second);	         
     }	    
     map.jumpTo(cameraOptions);

This PR fixes that behavior by using optional<mbgl::CameraOptions> instead of CameraOptions&.

[ChrisLoer]

This looks reasonable to me, but I think I'm missing something about how it works. It looks to me like the members of CameraOptions are already optionals, the default constructor will leave them empty, and jumpTo uses value_or(current map state) so that it should be a no-op with a default-constructed CameraOptions. Which part of that didn't work? It it something to do with the style loading asynchronously?

Also, how do we have android render tests hooked up to the MapSnapshotter? This is cool, I didn't even know it was a thing we did, but I'm embarrassed I can't find where it happens.

[tobrun]

been working on this for a while but was on the backburner (see #10045).

so that it should be a no-op with a default-constructed CameraOptions

The issue is that the style.json has a camera options definition but even without setting a camera position in java the style.json camera gets overridden. It could be that I can fix this on the java/jni side without any core changes, will need to try that out.

[ChrisLoer]

been working on this for a while but was on the backburner (see #10045).

Awesome! That will incidentally be a good stress tester for MapSnapshotter...

Aha, OK I get what's going on now. The camera options in the style end up in the defaultCamera object, and normally onStyleLoaded applies the default camera to the map object, but the earlier (empty) jumpTo call sets cameraMutated = true, and that short-circuits the use of defaultCamera in onStyleLoaded.

It might make sense to only set cameraMutated if something actually changes, but that might also cause some surprising behavior...