Athens: Add support for `~`, `^` and `<` in filtering

[michalpristas]

Is your feature request related to a problem? Please describe.
After #1050 is in we have a way how to enable specific versions of the module(those verified)
With repo being more active filtering might become a bit noisy which we can address by supporting ~ and ^

Describe the solution you'd like
With this issue fixed we will have 5 ways how to enable module:

• + repo: enables all versions of the repo
• + repo 1.2,1.3: enables just the listed versions of the repo
• + repo ~1.2.3: enables 1.2.x which are at least 1.2.3
• + repo ^1.2.3: enables 1.x.x which are at least 1.2.3
• + repo <1.2.3: enables everything lower than 1.2.3 includes 1.2.2 and 0.58.9 as well

[Kunde21]

The other extension I would like to have on the version filtering is handling multiple rule entries. We would need to define precedence rules, but I can see an approved list that has multiple approval points and one shared instance.

# entries from team A
+ github.com/gomods/athens v1.1,v1.3
# many other entries

# entries from team B
+ github.com/gomods/athens v1.2.1

Another option might be a block list that is append-only:

- github.com/buggy/mcbuggerson v2.27.301
- github.com/buggy/mcbuggerson v2.28.110
# and so on

The other capability this gives us is the ability to set a repo default in lieu of a global default:

# block bug factory repo by default
- github.com/buggy/mcbuggerson
+ github.com/buggy/mcbuggerson v2.28.35

# only block internal dependencies with known security vulns
D company.github.com/bigproduct/dependency
- company.github.com/bigproduct/dependency v2.1.1,v3.5.23

[fedepaol]

Can I grab this to get back on track?

[Kunde21]

Yeah, go ahead @fedepaol. Thank you!

[marwan-at-work]

Looking at @michalpristas 's examples in the description above, any reason the versions don't have a v prefixed in them? I feel like we should stay consist with how the Go community is starting to expect SemVer tags to look like.

Also, if

+ repo ~1.2.3: enables 1.2.x

Why not just make it + repo 1.2.x? where you can do 2.x.x and so on.

Also, I'd like us to step back and think more thoroughly about this:

Are these features worth the complexity? Is this feature widely used and widely requested?

I'm not against it, but personally I'll probably never use it which doesn't mean no one will, but I would love to see some sort of up votes before features are accepted.

[fedepaol]

@marwan-at-work I'll hold my keyboard, and I agree to not overcomplicate the filters.
We should think about general scenarios / use cases.
What comes into my mind is filtering a dependency that changed its license from a certain version, or wanting to adhere to a certain version of an api if/when the major changes.

[Kunde21]

Where I've seen this need is strict compliance department requirements, where approvals are only for specific version(s) of a dependency.

[fedepaol]

Under @arschles suggestion I tried to implement the part suggested by @michalpristas to see how it comes and to use it as a discussion point. Comments are more than welcome :-)