Files (and folders) are still slugified to ASCII for storage on disk,
but now the original filename is stored alongside in metadata.yaml
and used for display in the file list and print status.
The slicing dialog also inherits that display name for use as base
for the suggested GCODE name.
Internally, everything still depends completely on the slugified
ASCII version.
This implements #2094
System wide API key now offers a generate button like the user
API keys. Setting the API key directly to a value via the settings API
endpoint is now no longer possible, which should prevent setting it
accidentally thanks to the browser prefilling things where it shouldn't.
No delete button is offered for the system wide API key since it will
get automatically regenerated on server start if not set, so
regeneration is the only functionality here that makes sense.
If no API key is set in the user settings, the "delete" button is now
disabled. If a key is already set and a new one is to be generated, a
confirmation dialog makes sure this is really what the user wants. Same
for deleting an existing API key.
Both the system wide API key and the user specific API keys will now
only display a QRCode if there's actually a value for the key.
Also added API docs regarding header encoding, incl support for RFC 5987
for filename fields in Content-Disposition headers in multipart/form-data
parts, incl. an example of an upload request with a utf-8 encoded filename.
This fixes a simple typo in the API doc for fetching slicing profiles. The previous example had /profiles appended to it, whereas it should just be /api/slicing to fetch a list of all slicers and profiles.
The client now tries to detect if it's fast enough to process the
state updates usually send every 500ms, and if not notifies the
server to throttle the rate (e.g. to 1/1s, 1/1.5s etc).
Additionally, since the terminal tab of the client turned out to
be quite CPU intense when line number calculation, filtering etc
is enabled, the terminal tab now also falls back into a bit less
fancy mode if it detects its being processed too slow and optionally
even disables logging completely during printing (where a lot
of log messages need to be processed in a minimum amount of
time).
That way the UI should stay responsive even on very low powered
clients (e.g. chromium on a Pi), while printing.
* Renamed userjson to userdata, removed original userdata (developers will live if they need to ensure their supplied userdata is valid JSON)
* Input validation for userdata parameter - a HTTP 400 response will be generated if userdata can't be parsed as JSON
* Adjusted documentation accordingly
