Enabling policies to prioritize new flows when flow table is full

When the flow table of a GK block is full, a new flow doesn't get a flow entry, but the GK block will send the packet through the request channel; see callers of `send_request_to_grantor()` for details. When Grantor servers reply policy decisions for new flows that are not backed by a flow entry, the GK blocks responsible for those flows make an effort to add those policy decisions; see `drop_flow_entry_heuristically()` for details.

With the scenario above in mind, one can see that, under attack, lots of packets are going to be dropped in the request channel due to the limited bandwidth, Grantor servers are going to process policies on flows not backed by flow entries, and GK blocks, which are already under stress, are going to spend time trying to add those policy decisions. All of this happens without the awareness of Grantor servers, so policies cannot take action to lower the impact at overloaded GK blocks.

A possible solution is to flag the packets of flows that are not backed by flow entries. This way, policies can decide if the flow is important enough to deserve a policy decision, or if it's better to ignore the new flow altogether. This solution requires a couple of enhancements in Gatekeeper and Grantor servers:
1. Gatekeepers servers must add the flag to those packets. We can use the hop-count field of the internal IP header because it's updated with the hop count of the external IP header when Grantor servers decapsulate packets.
2. Grantor servers must enable policies to ignore requests for a policy decision at will. Currently, all requests for a policy decision must be fulfilled.

This solution enables policies to prioritize important flows such as those that involve business partners during an attack.