getRpcReply Method Blocks Until Data is Available From Netconf Device

[beserb]

This is my very first Github issue so bear with me if I missed any important ritual.

I noticed that when Netconf device does not respond to a RPC request, Netconf client hangs. I investigated the issue and found that it waits to read from channel input stream:

netconf-java/src/main/java/net/juniper/netconf/NetconfSession.java

Line 139 in c0fbeda

int charsRead = in.read(buffer, 0, buffer.length);

There is a timeout check in getRpcReply method in NetconfSession class but it only kicks in when there is data to be read from SSH channel input stream. Thus, there are 3 main problematic scenarios:

1. If Netconf device never sends data, getRpcReply hangs forever.
2. If Netconf device sends data in multiple chunks and stops sending anything before timeout is reached, getRpcReply hangs forever (technically same with scenario 1)
3. Timeout is actually determined by the sent data. Let's say timeout is 1000ms and Netconf device sends data in 2000ms. In that case getRpcReply wait for 2000ms. If data has the prompt chars, timeout does not occur, otherwise it occurs after 2000ms.

Main reason is, underlying input stream of SSH channel (PipedInputStream) provides blocking read. Therefore, it is better to check if there is data to be read before attempting read operation.

I have submitted regarding fix and adapted test cases accordingly. Tbh, I am not very proficient with streams and I may have analyzed the issue or implemented fix wrong. Please thread carefully :)