[Feature][DataLoader] Add catalog for loading tables

[robreeves]

Summary

This creates a Python OpenHouseCatalog that supports loading tables. Authentication and logging is modeled after the java implementation of the OpenHouse catalog.

I chose to make this inherit from the iceberg catalog. The reason for this is so that OpenHouseDataLoader can accept any Iceberg catalog and not be restricted to OpenHouse only.

The next step is to have OpenHouseDataLoader use the catalog to load the table and plan the splits. Retries for transient OH server calls will happen in that layer (e.g. retry for OSError exceptions). Here is an in progress PR for the next change.

Changes

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

New Features:

• OpenHouseCatalog - Inherits from PyIceberg Catalog, implements load_table via GET /v1/databases/{database}/tables/{table}. Accepts uri, auth-token, and trust-store properties matching the Java catalog.
• OpenHouseDataLoader now takes a catalog: Catalog as a required first parameter, making it catalog-agnostic.

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.

All tests pass via make verify

I also added a new integration test framework for data loader and make a catalog e2e test. Output:

  $ make integration-test TOKEN_FILE=../../../tables-test-fixtures/tables-test-fixtures-iceberg-1.2/src/main/resources/dummy.token
  uv run python tests/integration_test_catalog.py ../../../tables-test-fixtures/tables-test-fixtures-iceberg-1.2/src/main/resources/dummy.token
  Created table d_e2e.t_catalog
  Copied metadata from container to /tmp/d_e2e/t_catalog-87baa9a1-9f15-4c11-98bb-f35c0e70a592/00000-5be7fde5-61d4-4035-9cc0-95bdb0dde147.metadata.json
  load_table returned table with name=('d_e2e', 't_catalog'),
  metadata_location=file:/tmp/d_e2e/t_catalog-87baa9a1-9f15-4c11-98bb-f35c0e70a592/00000-5be7fde5-61d4-4035-9cc0-95bdb0dde147.metadata.json
  load_table correctly raised NoSuchTableError for nonexistent table
  Deleted table d_e2e.t_catalog
  All integration catalog tests passed

Output:

  Checking tables service is up...
    Service is up: {'status': 'UP'}

  Creating table test_db.test_table via REST API...
    Table already exists, fetching it...
    tableLocation: file:/tmp/test_db/test_table-5d385e0f-282c-4c85-b7a6-b086f1851fea/00000-dc25a2ea-5be7-40b9-888d-33a500143d63.metadata.json

  Testing OpenHouseCatalog.load_table('test_db.test_table')...
    Success!
    name: ('test_db', 'test_table')
    metadata_location:
  file:/tmp/test_db/test_table-5d385e0f-282c-4c85-b7a6-b086f1851fea/00000-dc25a2ea-5be7-40b9-888d-33a500143d63.metadata.json
    schema: table {
    1: id: required string
    2: name: required string
    3: ts: required timestamp
  }

  Testing load of nonexistent table...
    Correctly raised OpenHouseCatalogError: Table no_db.no_table does not exist

  Cleaning up table test_db.test_table...
    Deleted.

  All tests passed!

Additional Information

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