GeezerVison

Before this change, both the public LB form (LoadBalancing.vue) and the
internal LB form (network.js Internal LB action) hard-coded the algorithm
dropdown to ['source', 'roundrobin', 'leastconn']. Every Lb provider got the
same three options regardless of what the provider actually supported, so a
user could pick "leastconn" against, e.g., the OVN provider, only to get the
rule rejected later by validateLBRule. The capability is already declared
(NetworkElement.getCapabilities() -> Service.Lb -> Capability.SupportedLBAlgorithms)
and surfaced by listNetworks - we just weren't reading it.

LoadBalancing.vue (public LB - the create modal and the edit-rule modal):
  - Replaces the three static <a-select-option>s with a v-for over a new
    `supportedAlgorithms` data field defaulting to the legacy
    ['roundrobin', 'leastconn', 'source'] (so providers/networks that don't
    declare the capability behave exactly as before).
  - Adds fetchLbCapabilities() (called from fetchData) which:
      * resolves the network id from resource.associatednetworkid or
        resource.networkid,
      * looks up the network via listNetworks,
      * walks service[name=Lb].capability[name=SupportedLbAlgorithms] and
        splits the CSV into the dropdown list,
      * snaps newRule.algorithm to the first supported value if the previous
        default falls outside the new set,
      * swallows any error so we never break the page on a backend hiccup.

  listNetworks is the right endpoint here. listNetworkOfferings hard-codes
  only SupportedLBIsolation/ElasticLb/InlineMode/VmAutoScaling for the Lb
  service in createNetworkOfferingResponse, while createNetworkResponse
  walks the live provider's getCapabilities() and exposes everything we
  declared - including SupportedLbAlgorithms.

network.js (internal LB action):
  - Leaves the static option list in place but flags the spot with a TODO.
    Driving this declaratively requires AutogenView to support an async or
    function-valued `mapping[field].options`, which is a framework-level
    change and out of scope for this UI patch. A follow-up can convert the
    declarative mapping to a SFC and adopt the same approach as the public
    LB form.

The change is provider-agnostic: it benefits every Lb provider that
correctly declares SupportedLBAlgorithms. OVN gets {roundrobin, source};
VirtualRouter keeps {roundrobin, leastconn, source}; Netscaler/F5/etc.
will reflect whatever they declare, and providers without the capability
fall back to the legacy three.

This commit is intentionally self-contained on top of the OVN plugin work
so it can be cherry-picked into a dedicated upstream PR.

Co-Authored-By: Claude Opus 4.7 <[email protected]>

Extends the data-driven LB algorithm dropdown previously added in
LoadBalancing.vue (public-IP LB form) to the two remaining places
where the capability was still hard-coded as
['source', 'roundrobin', 'leastconn']:

- VpcTiersTab.vue: the "Add Internal LB" modal accessible from the
  VPC details page. The dropdown now follows the capability declared
  by the selected tier's Lb provider, looked up via listNetworks at
  the moment the modal opens (handleAddInternalLB ->
  fetchLbCapabilitiesForNetwork). Falls back to the legacy three when
  the lookup fails or the provider does not declare the capability,
  so providers without it behave exactly as before.

- AutoScaleLoadBalancing.vue: the "Edit rule" modal on a VPC public
  AutoScale LB. Same pattern - openEditRuleModal ->
  fetchLbCapabilitiesForRule reads the capability from the rule's
  tier network and narrows the dropdown to whatever the provider
  actually accepts.

LoadBalancing.vue: keeps its existing per-network lookup but adds a
fallback for the VPC case. When the public IP record exposes only
vpcid (the IP has not been associated to a specific tier yet because
no rule exists), the helper now picks any Lb-enabled tier of the VPC
via listNetworks(vpcid=..., supportedservices=Lb) and reads the
capability from that tier. Every tier of the same VPC uses the same
Lb provider, so the answer is provider-uniform.

The change is provider-agnostic - any Lb provider that correctly
declares Service.Lb -> Capability.SupportedLBAlgorithms benefits.
The OVN provider exposes {roundrobin, source}, VirtualRouter keeps
{roundrobin, leastconn, source}, NetScaler / F5 / etc. will reflect
whatever they declare, and providers without the capability fall
back to the legacy three. listNetworks remains the right endpoint
because the offering response only emits a fixed subset of Lb
capabilities while createNetworkResponse walks the live provider's
getCapabilities() and surfaces SupportedLbAlgorithms verbatim.

Co-Authored-By: Claude Opus 4.7 <[email protected]>