feat: provide UI backward compatibility for older lxd versions [WD-8671]

[mas-who]

Done

• Hide iso import functionality for storage volumes if the lxd server does not support the feature. This includes creating an instance based on custom ISO or attaching custom ISO to a running instance.
• Return empty server configs for lxd 5.0 instead of calling the /1.0/metadata/configuration endpoint
• Return empty doc string for lxd 5.0 instead of calling the /documentation api endpoint
• Remove features.networks.zones project config for lxd 5.0
• Remove features.storage.buckets project config for lxd 5.0
• Hide warnings page for lxd 5.0

QA

1. Run the LXD-UI:
   • On the demo server via the link posted by @webteam-app below. This is only available for PRs created by collaborators of the repo. Ask @lorumic or @edlerd for access.
   • With a local copy of this branch, run as described here.
2. Perform the following QA steps:
   • Downgrade lxd to 5.0/stable first
   • make sure you can't create an instance using a custom ISO, attach a custom ISO to a running instance via the Instance Console and the Custom ISOs tab is not visible on the storage page.
   • make sure the server settings page does not error out even it's mostly empty and that there is a notification asking users to upgrade to lxd 5.19 or later.
   • check the network tab in the browser inspect tool that on any configuration page, no network requests are made to the /documentation/objects.inv.txt endpoint
   • make sure that you can create project successfully, then try edit a project and can save it successfully. On the project details page, main configuration section, you should not see the check boxes for Network zones and storage bucket features.
   • make sure the warnings page is hidden from the side navigation

[webteam-app]

Demo starting at https://lxd-ui-647.demos.haus

[mas-who]

Things to think about

1. I wonder if there is a better and more generic approach to manage feature support? Going to think on this one for a bit.
2. Maybe we should start checking from lxd 4.0, then get a full list of features that doesn't work and that should inform which api extension to check for feature support. This is probably a good approach to establish a baseline assuming api extensions only have additions with lxd version increase from the perspective of the UI.

[edlerd]

2. Maybe we should start checking from lxd 4.0, then get a full list of features that doesn't work and that should inform which api extension to check for feature support. This is probably a good approach to establish a baseline assuming api extensions only have additions with lxd version increase from the perspective of the UI.

I am not sure how much 4.0 is still in use. I took this on our sync agenda for tomorrow, we can get more input from the core team on which lowest version to support. Likewise, I was previously under the impression 5.0 is fine.

[mas-who]

2. Maybe we should start checking from lxd 4.0, then get a full list of features that doesn't work and that should inform which api extension to check for feature support. This is probably a good approach to establish a baseline assuming api extensions only have additions with lxd version increase from the perspective of the UI.

I am not sure how much 4.0 is still in use. I took this on our sync agenda for tomorrow, we can get more input from the core team on which lowest version to support. Likewise, I was previously under the impression 5.0 is fine.

Aah great, thanks I was thinking about asking that tomorrow as well! I think if I know what the baseline lxd version is, then I can streamline the process to make this happen

[mas-who]

Will update PR notes in the morning.

[edlerd]

QA looks good, tested with 5.0 and a recent backend.

I found one issue and some small optional comments on code simplifications below.

[edlerd]

LGTM, thanks for applying the fixes :)