Add configuration setting for TO client request timeout
Closes: #7048
Which Traffic Control components are affected by this PR?
- Documentation
- Traffic Stats
What is the best way to verify this PR?
Ensure the all tests (especially CDN-in-a-box) continues to work and run. Traffic Stats should run whether the configuration value is present or not. It will default to the previous hard coded 10 seconds. However, now it should also accept the new "toRequestTimeout" value in the .cfg file.
As this requires an unresponsive/slow TO instance, testing can be difficult. This can be done locally with a debug build and breakpoints. You can put a breakpoint at the beginning of the TO GET v3.1/servers endpoint and waiting longer the alloted time (be it the 10 second default or whatever custom value you place) which will prevent Traffic Stats from receiving a response in time and cause the error to appear in the log. The error is:
[ERROR] 2022-08-30 14:36:10 Error getting server list from https://{{traffic_ops_url}}/: Get "https://{{traffic_ops_url}}/api/3.1/servers": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
The next time through you can remove the breakpoint and allow it to proceed normally. The error will not appear and TS will function normally.
If this is a bugfix, which Traffic Control versions contained the bug?
PR submission checklist
- [ ] This PR has tests - Traffic Stats has minimal testing support and would require significant refactoring for this test.
- [x] This PR has documentation
- [x] This PR has a CHANGELOG.md entry
- [x] This PR DOES NOT FIX A SERIOUS SECURITY VULNERABILITY (see the Apache Software Foundation's security guidelines for details)