Add backend_port_range attribute to haproxy-route-tcp relation

[Copilot]

What this PR does

Adds a backend_port_range field to TcpRequirerApplicationData in the haproxy-route-tcp library (v1, LIBPATCH 4). When set (e.g., "4000-4005"), it:

• Creates a single dedicated HAProxy frontend with bind :<start_port>-<end_port> for the entire range
• Omits the port from server entries in backend config (HAProxy binds the frontend port range directly)
• Exposes all ports in the range via open_ports (expanded via covered_ports property)

Library changes:

• backend_port_range: Optional[str] field with pydantic validators for format (split on - delimiter, validate exactly 2 valid port numbers), range bounds, and mutual exclusivity with port/backend_port
• requested_ports_in_range property returning the expanded list of ports
• configure_port_range() chainable method on the requirer
• Updated check_ports_unique to detect conflicts across entire ranges (overlap detection)

Operator state changes:

• HaproxyRouteTcpServer.port is now Optional[int] (None in port-range mode)
• HaproxyRouteTcpServer.server_address property encapsulates address formatting logic (returns address:port or just address depending on mode)
• HAProxyRouteTcpFrontend gains port_range_end, bind_port, and covered_ports properties
• parse_haproxy_route_tcp_requirers_data creates a single frontend per port-range backend (no expansion into N frontends)
• HAProxyRouteTcpFrontend.from_backends determines port_range_end from the backend's range
• Conflict detection uses covered_ports for overlap checking between port-range frontends and other TCP/HTTP/gRPC ports

Template: render_tcp_server uses server.server_address property directly; frontend bind uses frontend.bind_port — no conditional logic in the template.

# Requirer usage
self.haproxy_route_tcp_requirer = HaproxyRouteTcpRequirer(
    self, "haproxy-route-tcp", backend_port_range="5000-5010"
)
# Or via chaining
self.haproxy_route_tcp_requirer.configure_port_range("5000-5010")

Why we need it

Workloads that listen on a contiguous port range (e.g., database shards, media servers) need all ports exposed through HAProxy without requiring N separate relations or manual per-port configuration. Using a single frontend with bind :<start>-<end> keeps the HAProxy config compact rather than creating one frontend per port.

Checklist

• I followed the contributing guide
• I added or updated the documentation (if applicable)
• I updated docs/changelog.md with user-relevant changes
• I added a change artifact for user-relevant changes in docs/release-notes/artifacts.
• I used AI to assist with preparing this PR
• I added or updated tests as needed (unit and integration)
• If integration test modules are used: I updated the workflow configuration
  (e.g., in .github/workflows/integration_tests.yaml, ensure the modules list is correct)
• If this PR involves a Grafana dashboard: I added a screenshot of the dashboard
• If this PR involves Terraform: terraform fmt passes and tflint reports no errors

Test plan

• 7 new unit tests covering: valid port range parsing, single frontend creation from range, conflict detection (range overlapping single port), invalid format rejection, mutual exclusivity with port/backend_port, reversed range rejection
• Template rendering test verifying correct HAProxy config output (single frontend with bind [::]:5000-5002, servers without :port suffix)
• Full existing test suite (247 tests) passes without regression

Review focus

• Validator ordering in TcpRequirerApplicationData — validators run sequentially; validate_port_range_exclusivity depends on validate_backend_port_range_format having already validated the format
• Making port field Optional[int] is a library API change — existing requirers always pass port, so backwards-compatible, but worth confirming no downstream assumptions on port being non-None
• The bind_port property returns "4000-4005" for range frontends or "4000" for single-port frontends — used directly in the template's bind directive
• The covered_ports property returns all ports in a range — used for conflict detection and open_ports expansion
• Port range format validation uses simple string split on - delimiter (no regex) — validates exactly 2 elements and both are valid port numbers
• The server_address property on HaproxyRouteTcpServer keeps address formatting logic in the charmstate rather than in the Jinja2 template

Potential breaking changes

• TcpRequirerApplicationData.port is now Optional[int] (was int). All existing usage passes port, so no runtime breakage, but type checkers downstream may flag this.
• HaproxyRouteTcpServer.port is now Optional[int]. The server_address property handles both cases.

[Thanhphan1147]

@copilot rename this attribute to requested_ports_in_range

[Copilot]

Renamed in 5c6a117.

[Thanhphan1147]

@copilot We try not to have too much logic in the j2 templates. Refactor this to a property in the haproxy-route charmstate and render only the value here.

[Copilot]

Refactored into a server_address property on HaproxyRouteTcpServer in the charmstate. The template now just renders {{ server.server_address }} with no conditional logic.

[Thanhphan1147]

@copilot Don't do this because it will cause the haproxy config to become too big. Every backend with a port range will have its dedicated frontend that has bind :<start_port>-<endport>. A frontend with a port range will still need to be checked for conflicts against other TCP frontends. Conflicts will be determined by checking for overlap.

[Copilot]

Refactored in the latest commit. Port-range backends now get a single dedicated frontend with bind [::]:4000-4005 v4v6 instead of being expanded into N separate frontends. Added bind_port property (returns "4000-4005" or "4000") and covered_ports property (returns all ports in the range) to HAProxyRouteTcpFrontend. Conflict detection uses covered_ports to check for overlap against other TCP frontends and HTTP/gRPC ports.