Fix stale in-memory catalog state after an Iceberg ALTER

[NiclasHaderer]

After an Iceberg ALTER (e.g. ADD COLUMN) or table rename is committed, the catalog left the old IcebergTableInformation in schema.tables. A scan in the same connection then read the pre-ALTER schema.

This refreshes the published table info on commit and swaps it into the schema under the entry lock, for both ALTER and rename, so subsequent reads see the committed schema.

[Tmonster]

I guess this is to update the information schema immediately after an alter? Otherwise any read afterwards will do the same correct?

[NiclasHaderer]

Sorry, yeah that is what this is fixing. Im currently contemplating if I should instead trigger a refetch from the rest server to get the newest metadata. What do you think?

Edit: I think we should be able to reuse the response of the commit even...

[Tishj]

I'm not sure I like this fix
There is no guarantee that the table hasn't received updates before our rename, and we're potentially pasting outdated state over newer state.

I'd be much more inclined to just reset the state, so that it can be populated the next time it's scanned

[Tmonster]

I'm also wondering what the performance improvement is here. Unless MAX_TABLE_STALENESS is set, then only 1 extra round trip is made. Potentially you could use the response from the server, but variations in IRC spec implementations make me think this might become a headache later.

Is there a specific use case where we really need to prevent the extra round trip?