Description
#334 updated the help string of the quit_button traitlet. During its review, it became evident that this is probably a remnant of having the notebook UI built into the same application - which then was propagated to jupyterlab, etc.
We should look at either deprecating or repurposing the traitlet. This discussion came up in today's Jupyter Server meeting where two options were discussed.
Deprecation Route
If we took the deprecation route, we need to mark it as deprecated, but, as @jasongrout mentioned in #334, add the traitlet (or its equivalent) into nbclassic and lab. The only effect here is that, eventually, the server would no longer support that traitlet. That said, and historically speaking, it has taken extremely long times to lead to a deprecated entity's actual removal.
Repurpose Route
A repurposing of quit_button would consist of it actually be used by the server to prevent the server's shutdown via the REST API. In this case, we'd likely want to deprecate quit_button to be replaced by allow_shutdown (or something of that sort). I suspect this will be very similar to the evolution of notebook_dir to root_dir.
Since there is utility in preventing the server's shutdown via the REST API, the repurposing route seems less problematic and, actually, necessary. (There should be a way to prevent authenticated users from shutting down the server anyway.)
There is also an argument that both are necessary in that you may want to allow the server's shutdown via REST but hide the quit_botton in the UI. In this case, I think we'd still deprecate quit_button - pushing the actual button enablement decision to the client application (where they could use the server's allow_shutdown for "is this capability available").
Given these choices, I think I'd be in favor of repurposing quit_button.