Otherwise we will block ourselves, waiting for the restart command to
complete which it only can when we are no longer there.
Should reduce restart times on update significantly.
Downside is that we no longer can wait for the return code of the
call. However, that should be caught by our UI handler timing out for
the restart and showing an error prompting the user to restart
manually.
Old default behaviour of showing logged in users the update
notification stays default, but can now be disabled via the software
update plugin settings.
Additionally added the ignore button to the notification for users as
well (and made ignore entry in local storage user specific to still
show notification to other logged in users), plus a small hint that
in order to apply updates an admin is needed. Additionally now hiding
the notification on log out.
Closes#1739
Don't allow overwriting of "octoprint" config through plugins, don't
allow overwriting of already registered configs unless id to register
matches plugin identifier (in which case the already registered config
was probably a case of a copy-paste-error from another plugin).
Most caching is left to the client, by utilizing ETag and Last-Modified headers.
Where it was easily achievable, an additional server side miniature cache of intermediary
results was introduced (e.g. for the files). The regular cached decorator was not used
since it targets caching full responses, and the responses in question already contained
client request specific data. Caching "one step earlier" allows better usage of the cache here.
Also introduced a dependency on the scandir module, to get a bit of a performance boost
on os.walk and os.listdir (which have been replaced with scandir.walk and scandir.listdir
respectively). See https://github.com/benhoyt/scandir#background on why that made
sense.
There was a problem with software update checks configurations stored in
config.yaml for which the providing plugin was then removed, since those
check definitions then lacked their default values to be merged on whatever
was stored in config.yaml, causing incomplete check configurations as a
consequence over which the plugin tripped.
This patch fixes that in that it tracks which check config keys are provided
by plugins and only returns those as the active check configurations that
belong to plugins that are still in the system.
TODO: This is only half of the solution. Check configurations of plugins
that are being uninstalled should be removed from the config if the
user decides to remove any settings by the plugin too. We need some
adjustments in the lifecycle tracking in order to make this possible
however, so for now this must suffice to at least prevent any errors from
occuring when incomplete configs are encountered.
(cherry picked from commit 8af8b8f)
