Add member ID 32-bit int type validation for Iceberg table schemas

[li-ukumar]

Summary

• Adds validateMemberIdColumnTypes() to OpenHouseTablesApiValidator that rejects Iceberg table schemas using INTEGER type for member identity columns (memberId, actorId, profileId, customerId, sourceId, destId, etc.)
• Member IDs will overflow 32-bit int max (2^31) — all member identity columns must use LONG
• Integrated into both validateCreateTable() and validateUpdateTable()

Testing Done

• Unit tests: long memberId column passes
• Unit tests: int memberId column rejected (create path)
• Unit tests: non-member-ID int column (retryCount) passes
• Unit tests: new patterns (customerId, sourceId, destId) rejected
• Unit tests: exact pattern mid rejected
• Unit tests: underscore normalization (member_id) rejected
• Unit tests: int memberId rejected via update path
• ./gradlew :services:tables:build passes

[abhisheknath2011]

Seems like this is specific usecase for LInkedIn memberId. Can we have this validation in the internal li repo as the validation is specific to LinkedIn usecase considering this is OSS codebase? We would need to extend OpenHouseTablesApiValidator in the internal repo and that can be enabled by adding something like @primary annotation.

[cbb330]

this doesn't belong in api layer. it should live next to the existing schema validation logic on the server. check if that exists at all in the linkedin implementation.

also, what is the rollout plan? just fail users? thats not acceptable. we need an answer to:

1. existing tables
2. new tables

and minimum shippable code would have debug / log info only.

also need to attach e2e tests with spark or create table curl requests