Tables: add FeatureFlagsResolver seam to stamp featureFlags server-side

[cbb330]

Summary

Adds a server-side FeatureFlagsResolver seam so a deployment can stamp per-(database, table) runtime featureFlags onto table responses without forking the core handler. Stacked on top of linkedin#644 (which adds the featureFlags field + client capture). The open-source default resolves nothing, so this stays behaviorless until a deployment supplies its own resolver.

Changes

• Client-facing API Changes
• Internal API Changes
• Bug Fixes
• New Features
• Performance Improvements
• Code Style
• Refactoring
• Documentation
• Tests

New Features / Internal API Changes

• FeatureFlagsResolver interface: FeatureFlags resolve(String databaseId, String tableId, TableDto tableDto). Implementations must be cheap and never throw on the response path; returning null is the safe default.
• NoOpFeatureFlagsResolver: open-source default, returns null.
• ApiConfig registers the no-op as the default bean via @ConditionalOnMissingBean(FeatureFlagsResolver.class), so a deployment can override it with its own bean (e.g. @Primary/@Component).
• OpenHouseTablesApiHandler calls the resolver right after tablesMapper.toGetTableResponseBody(...) and stamps the result via body.toBuilder().featureFlags(...).build() on getTable, createTable, and updateTable. The mapper still ignores featureFlags — it is a request-time decision, not sourced from TableDto.

Why the default lives in ApiConfig (not a @Component)
The default resolver is registered in ApiConfig (package com.linkedin.openhouse.tables.api, already scanned by the prod app and the e2e SpringH2Application) instead of relying on component-scan of a new package, so the enumerated test scanners keep resolving the bean.

Example deployment override (e.g. li-openhouse)

@Primary @Component @Profile("!dev")
class LiFeatureFlagsResolver implements FeatureFlagsResolver {
  public FeatureFlags resolve(String databaseId, String tableId, TableDto tableDto) {
    // e.g. if tableId.equals("prod_db_changes_venice_test") -> stamp read-bridge ON
  }
}

Testing Done

• Manually Tested on local docker setup. Please include commands ran, and their output.
• Added new tests for the changes made.
• Updated existing tests to reflect the changes made.
• No tests added or updated. Please explain why. If unsure, please feel free to ask for help.
• Some other form of testing like staging or soak time in production. Please explain.

New FeatureFlagsResolverTest:

• the no-op resolver returns null;
• getTable stamps the resolver's FeatureFlags onto the response body;
• with the no-op resolver, getTable leaves featureFlags null.

Regression: :services:tables:test --tests TablesControllerTest (real handler via H2) passes, confirming the new @Autowired resolver resolves in the e2e Spring context.

Additional Information

• Breaking Changes
• Deprecations
• Large PR broken into smaller PRs, and PR plan linked in the description.

Sequence: linkedin#644 (response field + client capture) → this PR (server-side resolver seam) → deployment-specific resolver (e.g. li-openhouse) + a client consumer that acts on a recognized flag. Not stamped here: the snapshot/commit response path (OpenHouseIcebergSnapshotsApiHandler) and searchTables; can be added if flags are needed there.

Made with Cursor