rabbit_feature_flags: Rework the management UI page

[dumbbell]

Why

The "Feature flags" admin section had several issues:

• It was not designed for experimental feature flags. What was done for RabbitMQ 4.0.0 was still unclear as to what a user should expect for experimental feature flags.
• The UI uses synchronous requests from the browser main thread. It means that for a feature flag that has a long running migration callback, the browser tab could freeze for a very long time.

How

The feature flags table is reworked and now displays:

• a series of icons to highlight the following:
  • a feature flag that has a migration function and thus that can take time to be enabled
  • a feature flag that is experimental
  • whether this experimental feature flag is supported or not
• a toggle to quickly show if a feature flag is enabled or not and let the user enable it at the same time.

Here is how the new table looks like:

For stable feature flags, when a user click on the toggle, the toggle goes into an intermediate state while waiting for the response from the broker. If the response is successful, the toggle is green. Otherwise it goes back to red and the error is displayed in a popup as before.

For experimental feature flags, when a user click on the toggle, a popup is displayed to let the user know of the possible constraints and consequences, with one or two required checkboxes to tick so the user confirms they understand the message. The feature flag is enabled only after the user validates the popup. The displayed message and the checkboxes depend on if the experimental feature flag is supported or not (it is a new attribute of experimental feature flags).

Here is a screenshot of the confirmation popup for unsupported experimental feature flags:

The request to enable feature flags now uses the modern fetch() API. Therefore it uses Javascript promises and does not block the main thread: the UI remains responsive while a migration callback runs.

Finally, an "Enable all stable feature flags" button has been added to the warning that tells the user some stable feature flags are still disabled.

Here is a screenshot of the warning with the added button:

[dumbbell]

As of this writing, the branch contains a commit that adds three feature flags just to help test the branch. They will be removed before the merge.

These feature flags are:

• a_stable_ff, a stable feature flag :-)
• exp_sup_ff, a supported experimental feature flag
• exp_unsup_ff, an unsupported experimental feature flag

They all use an enable callback that throws an exception after sleeping two seconds.

CI will fail until they are removed because it will fail to enable a_stable_ff.

[michaelklishin]

This looks great.

[mkuratczyk]

There are two issues related to auto-refresh:

1. (discussed yesterday with @dumbbell) When using the "enable all FFs button", if there's an FF migration that takes more than the page refresh, feature flags that will be enabled later (are "queued" to be enabled) will turn red (because their state is not changing - they are still disabled)
2. when the experimental feature flag dialog appears with the warning, it disappears on page refresh

Both issues are relatively minor and the overall experience is already better. I don't insist we have to fix these.

[dumbbell]

@mkuratczyk: I finally found and implemented a fix for the issues you list where the auto-refresh is involved: I pause the auto-refresh timer and resume it at the end of handling feature flags.

I think there are still issues in this area. For example, if the user switches to another page and comes back. Or if they play with the auto-refresh dropdown menu at the top right. But I feel fixing this becomes out of scope for this patch. We can wait that a user reports them :)