fix(async-nats): add empty subject check

[hysyeah]

Background
The send_publish function previously did not validate for empty subject strings.
This oversight allowed empty subjects to be processed, which caused nats-server to incorrectly route request payloads to the respond box, then resulting in JSON deserialization failures.
like that:
Error: Error { kind: Other, source: Some(Error("data did not match any variant of untagged enum Response", line: 0, column: 0)) }

what this pr do
This PR adds a validation check for empty subjects in the send_publish, immediately returning an error when a subject is empty.

[Jarema]

Hey. Thanks for the PR. However, can you elaborate or show example how empty subject was affecting request/response patterns and routing?

[Jarema]

This should be validated on Core Nats level, with new error kind.

[hysyeah]

Hey. Thanks for the PR. However, can you elaborate or show example how empty subject was affecting request/response patterns and routing?

    let publish_result = js.publish(
        "".to_string(),
        serde_json::to_string(&event)
            .unwrap_or_default()
            .into(),
    ).await?;

call js.publish with empty subject, will cause nats core route payload to respond box.
like that

[hysyeah]

This should be validated on Core Nats level, with new error kind.

thank you for reply. I think this also need validated on async-nat, because empty subject name will never be valid, add a check to quickly return when the subject name is empty, avoiding unnecessary requests to the server. This also provides a clear error message.

[Jarema]

That's exactly what I'm asking for - add that validation for client.publish. It will also cover jetstream.publish.

[hysyeah]

@Jarema It appears that jetstream.send_publish does not call client.publish.
https://github.com/hysyeah/nats.rs/blob/ecf3182f3865b7d13ea23a61adc124c379007f3c/async-nats/src/jetstream/context.rs#L192

[Jarema]

@hysyeah jetstream send_publish is not using client,publish because jetstream publish is actually a request.
Nonetheless - it should be implemented across all methods. Let me know if you would like to do that or not. If not - that is ok. I can do it in core nats first.

[hysyeah]

@Jarema
Thank you for the clarification and for offering to implement this.

I think it would be best if you handle this implementation, starting
with core NATS as you suggested.