Bound streaming reader timeout by readTimeout instead of a fixed 30s

[kenhuuu]

The gremlin-driver streaming reader thread used a hardcoded 30s queue poll that ignored the configured readTimeout — so a client with readTimeout=0 ("no timeout", the default) was still cut off at 30s, and the failure surfaced as a raw IOException rather than a typed timeout.

The reader's wait now derives from readTimeout: 0 blocks indefinitely (matching the aggregated path), and a positive value arms a backstop set longer than readTimeout so the pipeline ReadTimeoutHandler fires first and terminates the response with a proper exception. ResultSet.markError is now first-writer-wins so a read-timeout and end-of-stream racing on the same request can't leave the recorded cause and the completed future disagreeing.

This surfaced as flakiness in shouldProduceProperExceptionOnTimeout on slow CI runners, where the reader repeatedly stalled on the 30s poll and pushed the test past the build limit. A 5-minute per-test timeout is added so a reader stall fails the test cleanly instead of hanging the build.

Review guide:
This most important part is that this PR determines how the streaming GraphBinary inputstream reader and readTimeout option need to combine together. Determine if the chosen path (have the InputStream respect the readTimeout) is the right path forward.

VOTE +1

[GumpacG]

I think there are CI failures related to the changes.
Can you also either make the names the same or more different as readTimeout and readerTimeout is too close to each other.

VOTE +1