Add filter tests

[LCVcode]

Describe the Bug

Filter expression are not recognized by the CLI, even when using the exact syntax from juju-jockey info. This fix must include additional testing that recognizes this regression.

At a minimum, we require:

• A matrix of tests which query each object type using each applicable filter.
• Testing all abbreviations in both the object names and the filter expressions.
• Testing all supported filters.

Here is an example of the filtering not working in the current code:

$ juju-jockey machine -f ../juju-status.json 'hostname~juju'
Usage: juju-jockey [-h] [-v] [-f FILE] [-H HOSTNAME] [-U USERNAME] [-S USERNAME] [-T SEC] [-J COMMAND] [-c DIR] [-C SEC] [--refresh] OBJECT [EXPRESSION ...]
juju-jockey: error: unrecognized arguments: hostname~juju

I tried several different filter expression syntaxes with no success.

Expected Behavior

Filters should be applied to the list of queries objects and return the result.

[johnlettman]

It looks like the tests will need to be expanded since this latest commit passed CLI:

https://github.com/LCVcode/jockey/actions/runs/10890835662/attempts/1#summary-30220415501

I'll take a look today

[LCVcode]

I am going to update the title and original description here to emphasize tests. This will help us understand the delta between desired and actual behavior.

[LCVcode]

@johnlettman Because we have a large delta in tests here, I think that taking a TDD-esque approach would be wise. I propose that we create a whole new branch in the repo to focus on this task.

This is multiple PR's worth of work, which will necessitate having failing tests on the new branch as we expand our testing coverage. I do not want to defy the CI that we have built on master.

Whatever abstraction we use to create these matrices of tests, it should be simple. I do not want this project to become over-engineered.

What do you think?

[LCVcode]

I am running a manual round of functionality testing to understand what needs to be done and what testing we need to implement now. Below are tables for my work thus far. In these tests, I am querying a single object type with a single filter. This process makes me suspect that our negative filters are just not working. For example, I could not come up with any case in which ^= or ^~ did what I expected. This may be responsible for some of the fails below, specifically the one in the first note at the bottom.

Row indicates object type and column indicates the object type of the filter.

Current	Unit	Machine	Hostname	Application	Charm	IP
Unit	pass	pass	fail1	fail	fail	fail
Application	fail	fail	fail	pass	fail	fail
Machine	fail	pass	fail	fail	fail	fail
Hostname	fail	fail	fail	fail	fail	fail
Charm	fail	fail	fail	fail	fail	fail
IP	fail	fail	fail	fail	fail	fail

Notes:

1. Filtering units by hostname seems to exclude all subordinate units:

$ juju-jockey -f tests/samples/k8s-core-juju-status.json units           
easyrsa/0
etcd/0
kubernetes-control-plane/0
calico/1
containerd/1
kubernetes-worker/0
calico/0
containerd/0

$ juju-jockey -f tests/samples/k8s-core-juju-status.json units machine=0
etcd/0
kubernetes-control-plane/0

$ juju-jockey -f tests/samples/k8s-core-juju-status.json units machine^=0
[empty]

For completeness, I rolled my repository back to commit c583f7a24deaeaa44380b89e8a29beaa56a43179, which is one of my final commits before we pulled in that first giant PR. Here is the same groups of tests:

c583f7	Unit	Machine	Hostname	Application	Charm	IP
Unit	pass	pass	pass	pass	pass	pass
Application	fail	fail	fail	fail	fail	fail
Machine	pass	pass	pass	pass	pass	pass
Hostname	fail	fail	fail	fail	fail	fail
Charm	fail	fail	fail	fail	fail	fail
IP	fail	fail	fail	fail	fail	fail

This is the regression that we need to resolve. While Jockey looks much better today, I think it has gotten into a less useful state. Maybe this is just a couple of bugs that are bogging down the current code base.

FYI: I am going to try to prioritize getting Jockey into a more refined state so I can do a live demo in about two weeks.

[LCVcode]

I am going to compare the current object collectors to see if we missed some nuance. I suspect we are not parsing subordinates properly in some cases.