Use /api/assetImage for imageUrl

In this change, we start using our new API endpoint for movie image URLs, instead of the Classic DTI image.

This should make the little fade-in phase for certain movies a little bit less jarring (the part where we preload the image before the movie loads), though I suppose that won't necessarily load as fast until it gets into the cache the first time lol. (A good reason to maybe put a more long-lived cache like Fastly in front of this stuff long-term?)

Not doing it for the smaller image sizes yet, I'm a bit worried that I don't 100% know how to teach /api/assetImage to resize without tipping over the function limit…

…oh! I should have the webpage render at different sizes! Yeah that's a great idea lol

src/server/types/AppearanceLayer.js

@@ -204,8 +204,25 @@ const resolvers = {
         if (format === "lod" && !jsAssetUrl && pngAssetUrl) {
           return pngAssetUrl.toString();
         }
+
+        // Or, if this is a movie, we can generate the PNG ourselves.
+        // TODO: Support this for smaller image sizes, too.
+        if (format === "lod" && jsAssetUrl) {
+          const httpsJsAssetUrl = jsAssetUrl
+            .toString()
+            .replace(/^http:\/\//, "https://");
+          return (
+            `https://impress-2020.openneo.net/api/assetImage` +
+            `?libraryUrl=${encodeURIComponent(httpsJsAssetUrl)}`
+          );
+        }
       }
 
+      // Otherwise, fall back to the Classic DTI image storage, which is
+      // generated from the SWFs (or sometimes manually overridden). It's less
+      // accurate, but well-tested to generally work okay, and it's the only
+      // image we have for assets not yet converted to HTML5.
+
       // If there's no image, return null. (In the development db, which isn't
       // aware which assets we have images for on the DTI CDN, assume we _do_
       // have the image - it's usually true, and better for testing.)