Progressive select timeout

[dafyddcrosby]

[NOTE] tests are being handled separately in #246, those commits will be gone once this has been rebased

Description

There doesn't appear to be a reason as to why READ_WAIT_TIME is 10 milliseconds, but that can be an excessive amount of time for quick shellouts. However, syscalls aren't 'free', so simply changing READ_WAIT_TIME to 1 millisecond would increase load where there's This PR adds a progressive timeout mechanism so that the timeout latency incrementally increases up to READ_WAIT_TIME.

Related Issue

#245

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Chore (non-breaking change that does not add functionality or fix an issue)

Checklist:

• I have read the CONTRIBUTING document.
• I have run the pre-merge tests locally and they pass.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• If Gemfile.lock has changed, I have used --conservative to do it and included the full output in the Description above.
• All new and existing tests passed.
• All commits have been signed-off for the Developer Certificate of Origin.

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud