refactor(alb): avoid options in ALB constructors

[Elia-Renzoni]

Description

This PR resolves a design issue in the Application Load Balancer (ALB) constructor, previously the time_series_merge constructor was relying on fields from the general Options struct that were not actually related to the ALB itself, but rather belonged to a more Backend-style configuration.

To address this and improve separation of concerns, I introduced a new ALBConfigs struct to replace Options in the constructor. This is because, in practice, load balancing algorithm constructors rarely need the entire Options struct, but rather just a few specific fields.

Changes

• Introduced ALBConfigs: Created a new struct tailored specifically for ALB requirements, decoupling it from the broader Options.
• Refactored Constructors: Updated the New factory functions to accept ALBConfigs instead of Options.
• Updated Tests: Refactored the test suite to align with the new constructor signatures and data structures.

Related Issue: #1011

Type of Change

• • Bug fix
• • New feature
• • Optimization
• • Test coverage
• • Documentation
• • Infrastructure

AI Disclosure

• • This contribution DOES NOT include AI-generated changes
• • This contribution DOES include AI-generated changes, and I have reviewed the relevant contributing guidelines.

[Elia-Renzoni]

I'm not sure if this is the best approach to solve the issue, so let me know what you think about it.

An alternative approach could be to create a custom NewTSM() constructor that accepts a specific TSMConfig struct rather than Options. However, having a different struct type just for this constructor might be confusing compared to the other algorithms. That said ALBs generally only use a subset of the Options fields in their constructors anyway.

[houyuwushang]

I took a pass over this from the #1011 angle. The CI is green, and I also checked the related packages locally:

• go test -count=1 ./pkg/backends/alb/...
• go test -count=1 ./pkg/backends/prometheus/...
• go tool golangci-lint run --timeout 5m ./pkg/backends/alb/...
• git diff --check origin/main...HEAD

Two things I think are worth considering before this lands:

1. tsm: narrow constructor input to a tsm.Config value type #1011 specifically proposed a narrower tsm.Config populated at the registry layer because OutputFormat is provider metadata rather than load-balancing behavior. This PR narrows the input compared with the full Options, but the new shared options.ALBConfigs still exposes OutputFormat to every mechanism constructor, and the TSM constructor still reads conf.OutputFormat. That may be the right tradeoff for constructor consistency, but it seems like the main design question for this PR: should this remain a shared ALB constructor config, or should TSM get its own small config type matching the issue proposal?

2. registry.New now calls options.NewALBConfigsFromOptions(opts) before dispatching to the mechanism constructor. Since NewALBConfigsFromOptions dereferences opts, registry.New(names.MechanismRR, nil, ...) would now panic even though the round-robin constructor itself does not need options and accepts nil. I do not see that on the main ALB startup path because alb.NewClient only calls registry.New with non-nil ALBOptions, so this may only affect direct package use/tests. Still, it may be worth either adding a nil guard in the conversion helper or adding a regression test that documents nil options are intentionally unsupported at the registry layer.

Not blocking from my side, but I think those two points would make the intended API boundary clearer.