Support for Key Search with Wildcards in NATS KV Methods

[burl21]

Proposed change

I would like to request support for wildcard searches in the following NATS KV methods: ls and rm. This feature would enhance the flexibility and usability of NATS KV by allowing users to list and delete multiple keys that match a certain pattern.

Use case

In scenarios where multiple keys follow a naming pattern, such as cache entries, logs, or configuration settings, being able to fetch or remove them all with a single wildcard query would save time and reduce code complexity. This feature is particularly useful in large-scale applications where the number of keys can be substantial.

Consider a bucket named test with the following entries:

•	test.cache1
•	test.cache2

Using the ls and rm methods with a wildcard, such as nats kv ls test "test.*" or nats kv rm test "test.*", should list and delete both test.cache1 and test.cache2, respectively. This functionality is crucial for efficiently managing related key-value pairs without having to handle each key individually.

Contribution

No response

[derekcollison]

The CLI ls is for buckets. However in the Go client, ListKeys can take a filter subject. Delete has no DeleteMulti at this point in time, but might be a good addition.

Not sure this is a server issues though. /cc @ripienaar and @piotrpio and @Jarema

[ripienaar]

nats kv ls BUCKET for keys, I will add a subject filter.

[ripienaar]

Actually, I do not see how ListKeys can take a filter - internally it always use WatchAll. We certainly could support that though.

[ripienaar]

Since delete is a put in reality, I am reluctant to do a range as we cannot do that in an atomic manner today

[Jarema]

Here is the ADR describing the new API in the clients: nats-io/nats-architecture-and-design#288

Clients will soon follow up with implementing them.
Here is the reference issue in Go client: nats-io/nats.go#1655

This does not include delete with wildcards, as that is a more complex story that requires server changes.

[Zetanova]

I hade an idea to virtual-bucket that is related to this issue
#5204 (comment)