Enhance set queries to support filtering by concrete object fields

The idea is also motivated by improving the IPAM feature set, but could also apply to any resource that supports set queries.

Why?

Let's say you have two networks, one IPv4 and one IPv6 tagged with type=interconnect metro=lax:

$ nsot networks list -q 'type=interconnect metro=lax'
10.20.30.0/24
2a01:75e0::/48

The only way to explicitly filter by IP version is to pass the -V/--ip-version flag:

$ nsot networks list -V 4 -q 'type=interconnect metro=lax'
10.20.30.0/24

$ nsot networks list -V 6 -q 'type=interconnect metro=lax'
2a01:75e0::/48

This works, but what if we wanted to filter by prefix length? What if we wanted to filter by a list of prefix lengths? This isn't possible with the naive "binary" (on or off, single-value) filtering of query filters.

Imagine being able to do this:

$ nsot networks list -q 'type=interconnect metro=lax ip_version=4'

If concrete fields were supported as part of set queries, the difference/intersection/union operations could also be supported, as well as potentially leveraging regex pattern matches for supported fields.

The downside is that this may be confusing, and we'd also need to assert that a resource cannot also have an attribute with a name that conflicts with a concrete field.

dropbox / nsot

Enhance set queries to support filtering by concrete object fields #222