frontend: eliminate unnecessary RwError construction (backtrace capture)

[BugenZhao]

As explained in #6131, capturing a backtrace on M1 Mac can be really slow after an LLVM upgrade. The profiling result shows that we're creating a lot of RwError, which captures the backtrace on construction, even though there's no user-facing error during the planning.

Actually, we're abusing the error handling of Rust: it's convincing that the compiler does not tend to optimize the code for the error branch which is believed to happen rarely, especially for the dev profile. We should prefer using Option in this case, or a lightweight error type (without backtrace capturing) at least.

Here're several functions that construct RwError frequently and hurt the performance a lot:

• Catalog::get_schema_by_name, Catalog::get_sys_table_by_name when binding table or source refactor(frontend): use CatalogError in catalog to avoid capturing unnecessary backtraces #6158
• Binder::bind_column when resolving subquery
• cast::least_restrictive when resolving array type (like array_concat.slt.part)

Note that we have eliminated most of the RwErrors in our system except for batch, and frontend, so that we can decide whether a backtrace is helpful and whether to put it in the per-module error type, instead of always capturing the backtrace as RwError does. So I believe the final solution should be #4077. 😄

We should consider eliminating unnecessary RwError construction them first. If this is hard, removing the backtrace from the RwError may also be a temporal workaround.

cc @xxchan @skyzh @fuyufjh @xiangjinwu

[skyzh]

Shall we also rethink about the TracedHummockError / TracedStreamError (but I believe they are only thrown when there's really an error)

[fuyufjh]

Hi, is this completed?

[xxchan]

I think it's done and similar situations in the future can be solved similarly case-by-case.