Fix: adds new filters functions

[TheGhoul21]

No description provided.

[TheGhoul21]

#1280
I think that actually everything could be brought to a unique implementation where we fill OrderedConfig with the correct additional key (namely filter_subject and filter_subjects).

Since is my very first commit I wasn't sure about that.

[Jarema]

Yes, this is correct. We were discussing having separate methods only because of compatibility with server version.

Instead we landed on this:
https://github.com/nats-io/nats-architecture-and-design/blob/main/adr/ADR-8.md?plain=1#L139

// KeysWithFilters returns a filtered list of keys in the bucket.
// Historically this method returned a complete slice of all keys in the bucket,
// however clients should return interable result.
// Languages can implement the list of filters in most idiomatic way - as an iterator, variadic argument, slice, etc.
// When multiple filters are passed, client library should check `consumer info` from `consumer create method` if the filters are matching,
// as nats-server < 2.10 would ignore them.
KeysWithFilters(filter []string) ([]string, error)

[TheGhoul21]

ok, I changed the code. I hope the way I instantiate the config is fine.
Tests are passing, I'm just not sure if it's the most idiomatic way to implement this.

[Jarema]

Hey!
Thank you for your contribution!

This looks pretty good.
Few comments made.

[Jarema]

I would add few more keys, and try a bit more complex filters and check them.

[TheGhoul21]

I added more tests following the docs here
I think filters in the format foo.b* are not supported, as * can only replace whole words, am I right?

[Jarema]

Functionally looks good, but one improvement requested.

[Jarema]

@TheGhoul21 are you interested in finishing this PR? 🙂

[TheGhoul21]

I pushed the changes you suggested.
The feature check fails when server_2_10 is not set. How should I handle that?

[Jarema]

@TheGhoul21 You need to put the function behind the feature flag

    #[cfg(feature = "server_2_10")]

[TheGhoul21]

keys() calls the same function for backward support, maybe something like this?

match (filters.next(), filters.next()) {
            (Some(first), None) => {
                config.filter_subject = first;
            }
            (Some(first), Some(second)) => {
                #[cfg(feature = "server_2_10")]
                {
                    config.filter_subjects = vec![first, second];
                    config.filter_subjects.extend(filters);
                }
                #[cfg(not(feature = "server_2_10"))]
                {
                    config.filter_subject = first;
                    // maybe a warning
                }
            }
            _ => {}
        }

I hate the duplicate code though

[Jarema]

Ah, right.

@TheGhoul21 The sole reason for utilising the feature flag is to avoid such situations where not all passed filters are properly set.

I'm afraid that duplication is the way to go here.
We can, however, after 2.11 is released, revisit this, as 2.10 will be the last supported version.

[Jarema]

This is not the way to go.

As said before - copy-paste is the way to go, for now.