server_fn feature propagation

[arpadav]

I have the ability to do the following:

# Cargo.toml
[dependencies]
leptos = { version = "0.8", features = ["rkyv"] }

and then

use leptos::server;
use leptos::server_fn::codec::Rkyv;
use leptos::server_fn::ServerFnError;

#[server(
    input = Rkyv,
    output = Rkyv,
)]
pub async fn example(input: String) -> Result<String, ServerFnError> {
    // ...
}

this is ergonomic, good 👍 . But, when attempting to do serde-lite, I have to manually import the separate server_fn crate:

# Cargo.toml
[dependencies]
leptos = { version = "0.8" } # `serde-lite` feat does not exist in `leptos`
server_fn = { version = "0.8", features = ["serde-lite"] } # separate crate def

and then

use leptos::server;
use server_fn::codec::SerdeLite;
use server_fn::ServerFnError;

#[server(
    input = SerdeLite,
    output = SerdeLite,
)]
pub async fn example(input: String) -> Result<String, ServerFnError> {
    // ...
}

Which is not that ergonomic.

I added other server_fn features to also propagate like cbor and whatnot, if people want to use leptos::server_fn rather than a separate server_fn instance.

Any need for this? It's mainly a QOL update

[gbj]

Thanks. This seems totally reasonable to me. Could you add this list of new features to the denylist down in [package.metadata.cargo-all-features] below? That will prevent our CI from trying to run them all, which becomes a combinatoric nightmare 😄 I don't think they need to be tested as they're all just passing through to server_fn.

[arpadav]

@gbj Okay I went ahead and added, let me know if looks good