Remove unused module ContainerSpecHelper

[flyrain]

It isn't used anywhere in the project, plus it causes potential extra maintenance cost like #1562.

[snazy]

This will be used by the NoSQL work.

[flyrain]

I don’t think it makes sense to create a standalone module just for a potential future persistence implementation. Even if this class is needed for NoSQL support, it should live within the NoSQL module itself, not in a separate module that adds unnecessary structure and overhead. Let’s keep the module boundaries meaningful and aligned with actual usage.

[eric-maynard]

Will it only be used by the NoSQL work? If not, maybe it can live outside the nosql module, but if so it should probably be contained there.

[snazy]

Use it for Minio, Keycloak, Postgres, etc etc etc.

[flyrain]

Use it for Minio, Keycloak, Postgres, etc etc etc.

Just to clarify, Postgres doesn't use it, and Minio and Keycloak are not part of the Polaris repo.
We also have no clear timeline or confirmation on whether they will be added, how they'd be integrated, or if they even belong in the repo at all.

[snazy]

TBH, I don't understand why you want to remove something that's known to be used by work that supposed to go in. We do add "dangling" pieces for upcoming work all the time. I don't understand why you're pushing to remove exactly this part.

[flyrain]

This isn’t just another piece of harmless scaffolding. It introduces public API.
Any public class becomes part of our compatibility contract. Once it lands, removing or reshaping it is a breaking change. That means we should only ship it when we’re confident in the design and need.

Dead code isn’t free.

• Security scans still review it.
• Binary and license audits include it.
• New contributors waste time tracing unused paths.
We carry that cost every release until the real feature arrives, and “temporary” code has a habit of sticking around.

[eric-maynard]

We do add "dangling" pieces for upcoming work all the time

I don't think I've personally ever added a dangling module for upcoming work, and I've scarcely seen it done in a way that wasn't super-specific to the upcoming work (e.g. a JDBC module for the upcoming JDBC work). We should try to minimize this, if possible.