Add a "Last Rendered" view to the webapp.
The Manager now stores (in the database) which job was the last
recipient of a rendered image, and serves that to the appropriate
OpenAPI endpoint.
A new SocketIO subscription + accompanying room makes it possible for
the web interface to receive all rendered images (if they survive the
queue, which discards images when it gets too full).
Add an operation to get the last-rendered image from whatever job received
such output from a Worker, and add a SocketIO subscription type to receive
updates about all jobs' last-rendered images.
These are necessary for a global last-rendered image display.
After processing an image in the "last-rendered" processor, a SocketIO
object is sent to clients to indicate the last-rendered image needs to
be (re)loaded.
This also moves the previously existing "done callback" from a single
function to a per-image callback, so that it can be called with the
right information in there, and only when that particular image is
actually done processing.
The notification message sent via SocketIO also contains the necessary
info to render the image, so that the web client doesn't have to call
the `fetchJobLastRenderedInfo` operation.
`SocketIOLastRenderedUpdate` objects are meant to be broadcast to SocketIO
clients (i.e. the web interface). They are sent to the job-specific room,
just like task updates.
It doesn't update automatically yet (still needs SocketIO notifications),
and there is no check yet for whether there is actually any last-rendered
image at all, but at least there is a component that shows the image.
Shaman prevents duplicate checkout directories, and communicates the actual
location back to the client. This wasn't used by the add-on though, so
the Flamenco job definition would point to the wrong files.
When installing, Blender will just unzip directly into the addons dir,
so the ZIP has to contain the `flamenco` package directory.
This also makes things simpler, naming-wise. We can offer the addon from
the Manager web interface as `flamenco3-addon.zip`, and still have it
install into the `addons/flamenco` directory.
This makes it possible to start Flamenco Worker at Blender Studio with
a worker-local current working directory, with the executable in a shared
filesystem.
Having the web API client override the HTTP port for the API URL is fine
during development (when the web content is served through the Vite
devserver), but not in production.
`os.IsNotExist()` is from before `errors.Is()` existed. The latter is the
recommended approach, as it also recognised wrapped errors.
No functional changes, except for recognising more cases of "does not
exist" errors as such.
Vue Router generates URLs for which there are no static files on the
filesystem (like `/jobs/{job ID}`). To make this work, the webapp's
`index.html` has to be served for such requests. The client-side JavaScript
then figures out how things fit together, and can even render a nice 404
page if necessary.
This shouldn't happen for non-webapp URLs, though. Because of this, the
entire webapp (including the "serve `index.html` if file not found logic)
is moved to a `/app/` base URL.
`make flamenco-manager` now also builds the webapp and embeds the static
files into the binary.
`make flamenco-manager_race` does NOT rebuild the static web files, to
help speed up of debug cycles. Run `make webapp-static` to rebuild the
webapp itself, if necessary, or run a separate web development server with
`yarn --cwd web/app run dev --host`.
Workers now send output produced by Blender (limited to PNG and JPEG
images, currently) to Manager. This is done by converting to JPEG first,
then sending the bytes via the Flamenco API to the Manager.
