DuckDB iceberg_scan post processor

This propose how we can support iceberg_scan thru duckdb.

The proposal has two parts: S3 auth, and iceberg_scan.

For S3 authentication, at the moment there is a new DuckDBS3AuthenticationStrategy, and when executing, is responsible of:

The second part is the connection post processor. This post processor translate table names following some rules:

There is a root path, where the post processor will concatenate for the iceberg_scan path
It expects that each schema and table are directories within the root path:
- root path: s3://warehouse/wh/
- Schema: nyc
- Table: taxis
- Original query: select * from nyc.taxis as "t"
- Translation: select * from (select * iceberg_scan('s3://warehouse/wh/nyc/taxis')) as "t"

Few challenges/questions/todos:

This does NOT include the required grammar for this to work on Legend Engine.
- Grammar / Composer for new S3 Auth strategy
- Grammar / Composer for new Iceberg Post Processor
Legend Pure relation does not support schema on the name yet, hence the test cases hardcode the schema name on the root path
Legend Pure relation only support INT and VARCHAR types
This assume we can have a private dyna function for the iceberg_scan translation, disabling an existing check
DuckDB at the moment expect some of Hadoop Iceberg hint files to find the right metadata files. This is improving on next version: https://github.com/duckdb/duckdb_iceberg/pull/63. This is visible on the test case setup to try to mimic this expectations
To avoid the DuckDB hint file requirement, we could integrate properly with an Iceberg catalog, and leverage its APIs to gather the latest metadata file

finos / legend-engine