Improvements around custom error handling in ServerFnError

[nicolas-guichard]

This implements a fix for #3154 by making NoDefaultError unhinabited, and proposes workarounds for #3153 and #3155 to make converting easier:

1. from Result<T, ServerFnError<NoCustomError>> to Result<T, ServerFnError<AnyOtherCustomError>>
2. from some Result<T, ServerFnError<SourceCustomError>> to Result<T, ServerFnError<TargetCustomError>> when TargetCustomError: From<SourceCustomError>
3. from Result<T, E> to Result<T, ServerFnError<AnyCustomError>> when E: std::error::Error, reflecting the existing From<E: std::error::Error> for ServerFnError<NoCustomError>

Usage examples are provided in the docstring for each of these new traits. My typical uses cases are:

• for 1. and 2. shared helper functions returning ServerFnError already, for instance a function that calls use_context.
• for 3. external functions that may raise an error, a database call for instance.

As mentioned in #3153 and #3155 I would have preferred implementing From<ServerFnError<SourceCustomError>> for ServerFnError<TargetCustomError> and From<E: std::error::Error> for ServerFnError, but as @benwis correctly pointed out those conflict with From<T> for T, at least until specialization becomes available.

[benwis]

I think there are some nice utilities here. Originally I had meant the server_fn_error! macro to convert Error into ServerFnError depending on the traits Error implemented. I suspect that can be expanded to handle some of these conversions here and land on a more general single trait.

[nicolas-guichard]

What's the target MSRV? The CI apparently uses an old Rust nightly 2024-08-01, and the build fails because omitting empty types in pattern matching is a Rust 1.82 feature.
The question is: should this handle Rust < 1.82 by adding the missing error::ServerFnError::WrappedServerError arm in ConvertDefaultServerFnResult::convert_custom_error?

[gbj]

We don't have an official MSRV policy but if it's simply a matter of adding a missing branch in a match, then yes you should add it.

[tqwewe]

Ironically, I do think Infallible would make sense here as the Err type for FromStr (since it implements Error), but this is a breaking change so not sure if its worth the effort.