The -t is the "torture" test that first runs the test and counts the number
of allocations performed during it, then it runs the test repeatedly over and
over again and makes alloc number N fail to verify that we detect and return
properly from error cases everywhere.

assume that the curl file is a proper binary, it is often a script file
produced by libtool.

for a reason I don't know

initial basic valgrind-log scan for memory leaks it could detect.

trace if a test results in a 'core' file and gdb is present

option instead (even though it appends the pid to the file name, making it
harder to figure out its name to parse it after a test has run).

Also made sure we only use valgrind for the actual test command command lines,
not when for example running curl to detect if there are any already running
servers are present etc.

we tell valgrind to use that to send the logfile to

display all logs and only logs with relevant data when a test fails and -p
is used.

when -p is used. For easier bug-hunting of autobuild failures. This still
only shows what files that are present in log/, as I believe we need to
filter which files we show on a failure.

Andrés García helped out!

test 99)

that to loadtest properly.

only accept return code 7 to indicate that there's no server present.

outside the source dir, not needing any symlinks

host), added retrying/waiting for slow stunnel startups

get some further input on the notorious test case 91 failures!

functionality

before we use it

Also made it easier to stop the test suite with control-c.

and we no longer use the stunnel.pm

curl and libcurl. -t is not used anywhere automated yet, and it does already
identify memory leaks on failed allocations. Work to do.

sure to clear them before we run the tests as they interfere badly otherwise.

of test cases that were "considered".

this runs on windows, to find out the current working directory.

them properly