async-nats: Support sample_freq values containing a %

[bengsparks]

Closes #1353.

This PR updates async-nats's deserialization routine for sample_freq in consumers to account for a terminating '%', which is seen in the wild when managing NATS resources using Terraform / OpenTofu.

The changed code is partially tested by the same test added in #1300, but currently does not contain a test for the new case.
I instead tested it against the setup outlined in #1353.
I'd like to add such a case, but I'm not sure how to do so, as Rust's type system forbids me from creating a consumer with sample_freq set to something ending in %.

[Jarema]

Hey!

Thanks for addressing the issue. The % was indeed the source of the problem.

The best way to test it send a custom request to JS API.

I wrote a quick and dirty example how to sent such request.
This should fail on main and work on your branch.

    #[tokio::test]
    async fn sample_frequency() {
        let client = async_nats::ConnectOptions::new()
            .connect("localhost:4222")
            .await
            .unwrap();

        let jetstream = async_nats::jetstream::new(client);

        jetstream
            .get_or_create_stream(stream::Config {
                name: "events".to_string(),
                subjects: vec!["events.>".to_string()],
                ..Default::default()
            })
            .await
            .unwrap();

        let consumer = json!({
            "stream_name": "events",
            "config": {
                "name": "consumer",
                "sample_freq": "10%",
            },
        });

        let info: Response<Info> = jetstream
            .request("CONSUMER.CREATE.events", &consumer)
            .await
            .unwrap();

        match info {
            Response::Ok(info) => {
                assert_eq!(info.config.sample_frequency, 10);
            }
            Response::Err { error } => panic!("expected ok response, got: {:?}", error),
        }
    }

[Jarema]

please add the mentioned test.

[bengsparks]

@Jarema
while adding the test, I've noticed an odd test here.
Both sections of the test use consumer::pull::Config, but the latter's name is "SampledPushConsumer".
This probably wasn't intentional? Should I add that change as part of this PR, or should I open a separate one for it?

In fact, I'd like to extend that test with your suggestion, as that test's purpose is to check the de/ser of sample_frequency

[Jarema]

nice catch!

yes, it make sense to fix it, however, let's make it a separate PR.
I prefer not cluttering PR with many changes.

[bengsparks]

Done in 5c5b36e.
I'll open the second PR after this one is merged

[Jarema]

LGTM!
Thanks for your contribution!