Fix CacheFetchProc in cases where the fileserver hates us

Fix CacheFetchProc in cases where the fileserver hates us

In some situations, the fileserver returns a large negative number
as the length in an FetchData64 call. The old FetchProc code used an int32
to hold this number, and checked length > 0 before attempting to read more
data. The new code uses a uint32, and does while (length), which causes the
cache manage to loop until RX aborts the connection.

This patch restores the old behaviour. length becomes a signed int once more
(and the original 32 bit length from the wire is used, rather than truncating
the 64 bit value), and the conditional checks for > 0.

Reviewed-on: http://gerrit.openafs.org/493
Tested-by: Derrick Brashear <shadow@dementia.org>
Reviewed-by: Derrick Brashear <shadow@dementia.org>