feat(catalog): impl builder for SqlCatalog

[335g]

Which issue does this PR close?

• Closes Implement catalog loader for sql #1626

What changes are included in this PR?

• Introduced a new SqlCatalogBuilder implementation for iceberg::CatalogBuilder.
• By transitioning the builder implementation from SqlCatalogConfig to SqlCatalogBuilder, we've simplified the process for creating SqlCatalog objects.
• Enabled generation of Box<dyn BoxedCatalogBuilder> for the SqlCatalog via the load function　(Implement catalog loader function. #1260)

Are these changes tested?

Yes (only tested whether it could be made）

[335g]

The implementation is complete and I'd like you to review it. 🙇

[liurenjie1024]

Thanks @335g for this pr! Left some comments to resolve.

[335g]

@liurenjie1024 Thanks for the review! I've addressed the comments you made. 🙇🏼

[335g]

@liurenjie1024 May I ask a question?
Currently, to comply with iceberg::CatalogBuilder, implementing Default is required. Why exactly is Default necessary? I understand it's needed for the load function in the iceberg-loader-catalog crate, but are there any other reasons?

SqlCatalog requires iceberg::FileIO, but implementing Default to allow users to select the storage location proves challenging. Currently, I'm considering implementing it by passing iceberg::FileIO as an argument to the initializer.

impl SqlCatalogBuilder {
    pub fn new(file_io: FileIO) -> Self {
        ...
    }
}

If possible, I'd like to remove Default from the iceberg::CatalogBuilder definition.

[liurenjie1024]

Hi, @335g I'm not convinced that we should remove Default for CatalogBuilder, as the default method provides a default constructor for it.

SqlCatalog requires iceberg::FileIO, but implementing Default to allow users to select the storage location proves challenging.

It's CatalogBuilder that requires implementing Default, not SqlCatalog. I took a look at the code and I think storing FileIO in SqlCatalogConfig is incorrect, FileIO should be inferred from warehouse location.

[335g]

Hi, @liurenjie1024 Thanks for the comment. I realized I didn't fully understand the previous comment. I've made some adjustments to the implementation - how does this look?

[335g]

Resolved conflict

[liurenjie1024]

Thanks @335g for this pr, generally LGTM! Just one minor point.

[liurenjie1024]

Oops, we need to resolve conflict first.

[335g]

Thanks @liurenjie1024 for review. The points you commented on have been addressed.

[liurenjie1024]

Thanks @335g for this pr!