frontend: PluginSettings: Rework plugin settings local storage usage

[vyncent-t]

Description

resolves issue #2595

This PR refactors the way Headlamp handles plugin settings stored in local storage, focusing on simplifying and improving the management of plugin states. Previously, the project stored the entire JSON data of plugin information in headlampPluginSettings, which included unnecessary details. This refactor reduces complexity by saving only the essential state information, improving performance and maintainability.

Key Changes

1. Simplified Storage:

   • Replaced the old headlampPluginSettings structure with enabledPluginsList in local storage.
   • The new structure saves only the plugin name and its on/off state, eliminating the need to store complete JSON data.

2. State Management Updates:

   • Introduced the pluginData slice in the plugin state to store plugin information.
   • Added enabledPlugins to maintain a list of plugins currently in use.

3. Backward Compatibility:

   • The project now detects the existence of the old headlampPluginSettings in local storage.
   • If detected, it converts and migrates the old settings into the new enabledPluginsList format automatically upon visiting the plugin settings page.

---

Steps to Test

To verify the changes and ensure backward compatibility:

1. Setup:

   • Start on the main branch with multiple plugins installed.
   • Disable one plugin while keeping others enabled, and save the settings.
   • Open the browser’s local storage and confirm that the disabled plugin’s state is saved in the headlampPluginSettings JSON.

2. Switch to this Branch:

   • Checkout this branch and navigate to the plugin settings page.

3. Observe Migration:

   • Confirm that the page detects the headlampPluginSettings in local storage, migrates the settings into a new enabledPluginsList object, deletes the old headlampPluginSettings, and reloads the page.
   • Verify that the plugin states from the previous settings are preserved in the new format.

4. Post-Migration:

   • Ensure that plugin settings updates are correctly saved in the new enabledPluginsList structure.
   • Confirm that enabling/disabling plugins reflects accurately on subsequent reloads.

---

Notes

• It improves the performance and clarity of plugin state management by reducing storage overhead.
• The migration process ensures a seamless transition for users upgrading from previous versions.

[vyncent-t]

last push

• allows old storage settings to be migrated to the new settings

[vyncent-t]

last push fixes merge conflicts

[vyncent-t]

last push rebases and fixes storybook

[joaquimrocha]

I am a bit surprised this needs so many changes. Wasn't the idea just to remove the saving of the whole package.json from the settings and use just the plugin name instead? Even if we change the name of the key in local storage, or move it to index db, why are we touching the plugin settings this much?

I would also like to understand: are plugins now supposed to be disabled by default? I understood that shipped plugins need to be enabled by default, and that the other ones were also like that for keeping a consistent behavior with the previous versions.

[vyncent-t]

noticed some weird behavior when not using any of the old headlampPluginSettings or enabledPluginsList in local storage, working on a fix again

[vyncent-t]

some meeting notes

• can keep the enabledPluginsList to handle toggles
• may need to handle default loading state of a plugin if they come disabled or enabled but most come enabled as of current
• handled the backwards compatibility for users on pervious vers that allow migration of old settings to new settings