ENH: Allow user settings for Auspice settings

[corneliusroemer]

Context

In Nextclade we have now got user settings/preferences that are saved in a cookie.

With things like show all branch label switch, it'd be cool if we could have similar user preferences in Auspice that apply across auspice sessions. I'd not want to toggle this every time I change coloring, or open a new tree.

Some people might prefer one, others something else. Setting defaults is good, but allowing a bit of preference customization is also nice.

We could treat user settings/preferences as secondary to URL parameters, for example, so that when I open a particular URL and a URL parameter is set, it overwrites the user preference.

[joverlee521]

Hmm, how would this interact with the dataset defaults?
Dataset maintainers may want to present their analyses in a particular view, hence they set the display_defaults.

(Not against user settings, just thinking through how all the different possible settings interact)

[emmahodcroft]

I think it would be better to put 'show all' as an option in the display settings of the JSON file - I think I may have spoken about this with James already somewhere.

[jameshadfield]

Background: Auspice UI settings, such as which colouring to use, are set on page load by consulting the display_defaults in the dataset JSON and then by considering the URL query. The intention of this is to both allow the dataset maintainer to configure the presentation and then to allow URLs to be shared which will recreate the view as you see it. However not all UI settings are available to be set as display defaults or via the URL query. There are a few reasons for this: sometimes it's just not sensible to encode this, sometimes adding this config is a commitment to backwards comparability so I want to wait until we are happy with the UI functionality first, and sometimes it's simply because we haven't got around to it!

I'm not sure how user session state would play with these concepts... I totally get that it's frustrating when something is not URL-encodable, but this is often because we lack the developer time to get it implemented and so adding another source of state which requires work for each new UI element isn't going to fix this. I think were session state to be in the mix here it would have to be in sync with the URL query so that we preserve the ability to share URLs like we do now.