This isn't strictly necessary, but since tests are now running
in parallel, it doesn't hurt to give slower machines more time
to complete these tests and this gives a little more headroom
for potential changes that subtly affect the behavor of the
components involved (like boost new versions).
There's a set of two tests for each perfdatawriter, just
to make sure they can connect and send data that looks reasonably
correct, and to make sure pausing actually works while the connection
is stuck.
Then there's a more in-depth suite of tests for PerfdataWriterConnection
itself, to verify that connection handling works well in all types
of scenarios.
Co-authored-by: Yonas Habteab <yonas.habteab@icinga.com>
