deny_traffic field in frontends

[Keksoj]

This field deny_traffic replaces cluster_id being an option, when None meant DENY.

Related to #997 and #996

[Geal]

I think my point from #997 (comment) was not clear.
There are very good reasons to separate the matching rule (frontends) from the routing decision (ClusterId), and you'll see most web servers and proxys clearly separate them (example: ACLs in haproxy).

When you start putting the routing decision in the matching rule, then that means that the rules or routing decisions become much less reusable. And when you want to add more routing decisions, then you end up stuffing the matching rule struct with more and more fields, until you want to break them out in a separate structure, but now removing fields from this public structure breaks the public API and existing config.

Also, I'm not sure about the state of the code right now, but there was a clear semantic difference between:

• cluster_id = None => we know about this frontend (like, an app declares that domain) but there are no servers to associate to it (the app has not started yet), which results in a 503 response, for which Clever Cloud has a specific page to show
• cluster_id = Some(Deny): you are not allowed to make this request, so 401. Easy way to shut out scanning bots, very different from the 503 response
• cluster_id = Some(id): we have a set of servers to associate here (but might still return a 503 if none of them answer)

[Keksoj]

You're right. After reviewing the issue several time, there is no concrete improvement to be made here.