refactor: enhance error handling with custom ConfigError type

[codope]

• Created ConfigError enum for more robust error handling
• Updated ConfigParser trait and its implementations to use ConfigError
• Modified HudiInternalConfig, HudiReadConfig, and HudiTableConfig to leverage ConfigError
• Adjusted tests to align with new error handling

[codecov]

Codecov Report

Attention: Patch coverage is 95.12195% with 2 lines in your changes missing coverage. Please review.

Project coverage is 87.17%. Comparing base (c454088) to head (c01adc4).
Report is 20 commits behind head on main.

Files	Patch %	Lines
crates/core/src/config/mod.rs	77.77%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #59      +/-   ##
==========================================
- Coverage   87.19%   87.17%   -0.02%     
==========================================
  Files          13       13              
  Lines         687      702      +15     
==========================================
+ Hits          599      612      +13     
- Misses         88       90       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[xushiyan]

that's a nice improvement. I would suggest capture underlying error as source, like ParseError should capture std::ParseIntError, etc, and NotFound should capture which key (ConfigParser) it refers to.

On a bigger scope, we should definitely standardize error types throughout hudi-core and other hudi crates. I chose anyhow for fast iteration and uncover error handling paths first. So all errors come out from hudi are now anyhow::Error. I suggest replace anyhow dependency with well-defined custom error enums implemented with thiserror in the next release.