relay: Onionskin wait cutoff and MaxOnionQueueDelay in queue should be consensus parameters

Our onion queue code, using the CPU thread pool, has this value hardcoded:

  /** 5 seconds on the onion queue til we just send back a destroy */
  #define ONIONQUEUE_WAIT_CUTOFF 5

This is used when we add an onionskin to the queue, we will drop any requests that has been longer than that in the queue by sending a DESTROY.

There is also a torrc option named MaxOnionQueueDelay that behaves a bit differently. If it takes tor more time than that value to process an ntor, reject it.

Both of these should be consensus parameters because they can affect strongly how our relays behave in times of load or attack like at the moment. For instance, under the DoS conditions of the network, it is possible (unproven) that extending MaxOnionQueueDelay to a longer wait time could result in less overload from our relays. But, this is a torrc option meaning that if not all 6000 relays update at once, we might have this partitioning problem.

If one group of the network sets that value higher leading to more room to handle onionskins, it means that these relays will have a higher CBT value which would transition circuit creation away from them to more overloaded relays.

If the network all at once change that value, CBT should in theory remains uniform for all path but just that all the sudden, circuit creation fails less but takes more time.