Add experimental mode

[NicolasDorier]

This add a configuration --experimental or experimental=1 in config file new server policy to show or hide features that are still unstable.

I added the custodian works of @woutersamaey in this category, as we should release it when we have at least one custodian in a plugin so we can dogfood the API a bit.

ExperimentalRouteAttribute will disable a controller if we aren't in experimental mode, by sending 404 error.

x_experimental: true in the swagger json file will remove the doc if not in experimental mode.

I am mixed on making it a config parameter rather than a server policy. But I can't find a good category to put such checkbox in the UI. @dstrukt

I believe it should be a server policy to make it easier to people to activate and try new features so we can gather feedback.

EDIT: Added a "Enable experimental features" in the server policies.

I also refactored to make it possible to expose settings from the SettingsRepository as services in the DI, this allow us to remove lot's of coupling to SettingsRepository, remove some places where we were doing .GetAwaiter().GetResult(), and remove some async/await.

[dstrukt]

Echoing what I said on MM:

Based on everything I understand from reading the ticket seems like a "switch" with a bit a of helper text in the "Server Settings" would be the most logical place at the moment (considering this is def an Admin feature). I could see it being in "Policies", probably the best place among the tabs .. or if it will become more involved than a simple ON/OFF switch OR we want a more clearly delineated place, maybe it deserves a new tab in the SS.

Which makes me wonder if we should introduce the idea of a "General/Overview (TBD naming)" tab in Server Settings .. which the user would land on by default, and would have stuff like "BTC Node: Synced/Running", "Version #: 1.6.0.1 -- Upgrade", etc.. and this switch/sub-set of features would fit in there nicely .. but might be worth more discussion, or could consolidate another tab (Maintain., etc..) into something like this.

cc @d11n

[pavlenex]

How could we keep a list of experimental features? I assume that user would always like to know what they are opting in for, if we bluntly say experimental features, then they will come and ask, which features are those?

How would we determine when a feature is experimental?

[woutersamaey]

Maybe just keep thing simple? Just put "beta" next to the item in the GUI? (once we have a minimal GUI that is)

[NicolasDorier]

@pavlenex I don't think we should keep a list.
Experimental features don't have to be advertised. It is meant for developers to dog food a feature before announcing.

The devs can find some testers that are interesting on the mattermost and tell them to activate experimental features.
For @woutersamaey, this is the case and it will also allow him to move forward with the Kraken's plugin.

We can't really put a beta in the GUI, as it is for feature we don't want to advertise yet. And for the custodian stuff, we don't even have a GUI for it.

[pavlenex]

Experimental features don't have to be advertised. It is meant for developers to dog food a feature before announcing.

Makes sense!

[NicolasDorier]

I believe that @woutersamaey with Kraken/Zappier integration dog food might have to change the API a bit.

[woutersamaey]

Correct. Some minor changes will be coming to the API to support the UI.

[woutersamaey]

@NicolasDorier How do I activate experimental mode now?

Also still looking to get some help on setting up plugin dev in Rider. Maybe @dennisreimann can help? I got the project set up, but the plugin does not build or activate somehow.

[woutersamaey]

For anyone looking for this, I found the "Enable experimental features" setting as a checkbox under Server Settings > Policies.