fix(iceberg): only convert iceberg table to iceberg source for batch dql

[chenzl25]

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.

What's changed and what's your intention?

• We should only convert the iceberg table to iceberg source for batch dql, since other batch sql (especially dml update and delete) should read the hummock table and use indexes to improve the performance and freshness.

Checklist

• I have written necessary rustdoc comments.
• I have added necessary unit tests and integration tests.
• I have added test labels as necessary.
• I have added fuzzing tests or opened an issue to track them.
• My PR contains breaking changes.
• My PR changes performance-critical code, so I will run (micro) benchmarks and present the results.
• My PR contains critical fixes that are necessary to be merged into the latest release.

Documentation

• My PR needs documentation updates.

Release note

[kwannoel]

What's the difference between using iceberg table for DQL and iceberg source for DQL?
When running DQL against iceberg table does it use the row-based replica rather than the actual iceberg table, and hence we convert it to iceberg source?

I suppose we may also want to let user configure this down the road, since their SQL could have a combination of DQL and DML.

[chenzl25]

What's the difference between using iceberg table for DQL and iceberg source for DQL? When running DQL against iceberg table does it use the row-based replica rather than the actual iceberg table, and hence we convert it to iceberg source?

I suppose we may also want to let user configure this down the road, since their SQL could have a combination of DQL and DML.

Let me change the ambiguous word iceberg table and iceberg source to row store and column store. The column store and the row store, which is the best one we want to use. As we don't have a cost-based optimizer to help us compare the cost among different plans, we should choose a default option for users. For DML, it seems choosing the row store is more beneficial since we can utilize indexes to accelerate point update/delete and more importantly there is a freshness lag between row store and column store right now, if we read column store to performance dml, which means we can't manipulate a row until it has been committed to iceberg, which might be a bad use experience for a demo. Last, it's fair to provide a session variable to allow users to control whether read row store or column store.