Make it possible to use feature flags to override the global timeout for specific pages

Robert said something very close to this:

"I want to lower the global timeout more but we have same pages which are all of:
 - infrequently used
 - extremely hard to optimise today
 - slow
so I've proposed and I think you were ok, with making the timeout overridable per page but this needs a unique-enough key to identify the page in the appserver. I had been thinking to use the page id, but I'm not entirely sure now whether its unique enough or even appropriate."

I agreed, pageids were not designed for that. Robert continued:

"I was actually thinking to lookup (key) as a feature flag scope. As long as (key) shows up in oopses, that would be a very low friction means to change this. As in, a sysadmin could just do it, when a page starts blowing up in future, file a critical bug, we fix, rule gets removed returning it to the default."

I mentioned that we could not try to change pageid for now, and that we could maybe use the full view class name for a key, but it might be tricky, because of dynamically created classes from some old Zope code we still use, for one thing.

Robert proceeded.

"The key constraints in the short term are:
 - deterministic key;
 - lookup in features;
 - control per-request timeout if a feature rule is found; and
 - key shown in oops somehow.
The uniqueness needed is that we should be identifying a code path reasonably precisely. Adding stuff to the oops is easy via the request vars dict, we can wedge it in any old how."

I questioned whether looking them up in feature flags were a short-term requirement. Robert replied:

"It is because:
 - we don't know -completely reliably- whats going to go *boom* when we change the global timeout
  - when we change it, we'll be flooded with issues, and the config system takes about 1.5 hours to make a change."

I conceded the point.