HTTP client request queue can grow unbounded in passive-backup mode

If the primary is able to process DHCP work faster than the passive-backup can respond to lease updates it is possible for them to accrue within the primary in the http::ConnectionPool::Destination::queue_. DHCP packet queue size and parking lot limits likely do not mitigate this for obvious reasons. It may be possible to mitigate it by reducing the number of DHCP threads versus the number of HA+MT threads but that's speculation on my part.

This can be readily demonstrated by running the passive-backup under valgrind, which slows the process down enough to make the accrual very predictable.

Tomek suggested possibly a warning log for now. We could monitor queue size and report periodically when it is growing. Note that when the traffic rate slows or stops, the backlog does get cleared and all updates are applied.