Refactor Standalone EndpointPool initialization to ensure Test/Prod parity

[LukeAVanDrie]

What would you like to be added:

I propose refactoring the logic that constructs the datalayer.EndpointPool for Standalone mode (currently residing in cmd/epp/runner/runner.go) into a reusable library function.

Current State:

1. Production: runner.go parses CLI flags (--endpoint-selector, --endpoint-target-ports) and manually constructs the EndpointPool struct, performing logic like slice initialization and map conversion.
2. Testing: test/integration/epp/harness.go (in WithStandaloneMode) manually reconstructs a similar EndpointPool object to inject into the Datastore, bypassing the CLI parsing logic entirely.

Proposed Change:
Extract the construction logic into a shared function (e.g., in pkg/epp/server or pkg/epp/datalayer):

func NewEndpointPoolFromOptions(namespace, name, selector string, targetPorts []int) (*datalayer.EndpointPool, error) {
    // Logic to validate, initialize slices, and return the Pool
}

Both cmd/epp/runner and test/integration/epp should use this shared function.

Why is this needed:

This addresses a wiring gap between our production binary and our hermetic integration tests.

Recently, a regression (#2092) occurred in Standalone mode where the target ports slice was copied incorrectly in runner.go, leading to a panic on startup. Even with the new integration tests for Standalone mode (#2175), this bug would not have been caught because the test harness re-implements the object construction logic instead of exercising the actual production code path.

By sharing this initialization code, we ensure that logic errors in configuration parsing are caught immediately by the integration suite.

Additional Context:
While a smoke E2E test for standalone mode (to be tracked in a separate ticket) would also catch this class of bug by running the actual binary, maintaining unit/integration parity is valuable for faster feedback loops and cheaper debugging. Both approaches are independently valuable.

[LukeAVanDrie]

cc @capri-xiyue

/help
/good-first-issue

[k8s-ci-robot]

@LukeAVanDrie:
This request has been marked as suitable for new contributors.

Guidelines

Please ensure that the issue body includes answers to the following questions:

• Why are we solving this issue?
• To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points?
• How can the assignee reach out to you for help?

For more details on the requirements of such an issue, please see here and ensure that they are met.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-good-first-issue command.

Details

In response to this:

cc @capri-xiyue

/help
/good-first-issue

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[varad-ahirwadkar]

/assign

[varad-ahirwadkar]

Hi, I am going through the code to understand how datalayer.EndpointPool is constructed. I looked at the Standalone path in cmd/epp/runner/runner.go, where the pool is built directly from CLI flags. I also went through test/integration/epp/harness.go to see how the integration tests exercise this flow. I noticed that the tests rely on the controller based path via CRs, and I am trying to understand this behavior.