resume: consider a resume from [content-length] to be OK

Basically since servers often then don't respond well to this and
instead send the full contents and then libcurl would instead error out
with the assumption that the server doesn't support resume. As the data
is then already transfered, this is now considered fine.

Test case 1434 added to verify this. Test case 1042 slightly modified.

Reported-by: hugo
Bug: http://curl.haxx.se/bug/view.cgi?id=1443

tests/data/test1434

@@ -0,0 +1,90 @@
+<testcase>
+<info>
+<keywords>
+HTTP
+HTTP GET
+Resume
+</keywords>
+</info>
+
+# Server-side
+<reply>
+# Some servers (e.g. Apache 1.2) respond this way to an invalid byte range
+<data>
+HTTP/1.1 200 OK
+Connection: close
+Content-Length: 100
+Content-Type: text/plain
+
+012345678
+012345678
+012345678
+012345678
+012345678
+012345678
+012345678
+012345678
+012345678
+012345678
+</data>
+
+# The file data that exists at the start of the test must be included in
+# the verification.
+<datacheck>
+012345678
+012345678
+012345678
+012345678
+012345678
+012345678
+012345678
+012345678
+012345678
+012345678
+HTTP/1.1 200 OK
+Connection: close
+Content-Length: 100
+Content-Type: text/plain
+
+</datacheck>
+</reply>
+
+# Client-side
+<client>
+<server>
+http
+</server>
+ <name>
+HTTP GET resume at exactly the existing file size is fine
+ </name>
+ <command>
+http://%HOSTIP:%HTTPPORT/1434 -C 100
+</command>
+<file name="log/curl1434.out">
+012345678
+012345678
+012345678
+012345678
+012345678
+012345678
+012345678
+012345678
+012345678
+012345678
+</file>
+</client>
+
+# Verify data after the test has been "shot"
+<verify>
+<strip>
+^User-Agent:.*
+</strip>
+<protocol>
+GET /1434 HTTP/1.1
+Range: bytes=100-
+Host: %HOSTIP:%HTTPPORT
+Accept: */*
+
+</protocol>
+</verify>
+</testcase>