Fix timing issue where a disconnected node is being requested & returned

[stevschmid]

This PR fixes the issue outlined in rubycdp/cuprite#239.

I fixed this initially by adding a node.isConnected check to Cuprite.isVisible, but after digging a bit deeper, it seems that the node get disconnected between the call for _cuprite.find and its handle_response. In this case we request a node via DOM.requestNode which is not connected to the document anymore and does not seem to get obsolete (subsequent commands such as #visible? never raise NodeNotFoundError).

I'm not sure this is the right place, maybe adding a disconnected check in Cuprite Node might be a bit less invasive. Please tell me what you think.

[espen]

I am facing a similar issue in my tests. It will occasionally fail. However never when I do a puts page.body before interacting with the node.

While I only did very minimal testing I was not able to reproduce this bug with this patch.

[route]

While separating Ferrum and Cuprite I had only one idea — Ferrum should be very simple and straightforward. For example you want to get a node that's fine here it is, Ferrum doesn't care if node is visible/disconnected or disappear in the DOM while still being exist in ruby world. Cuprite on the other hand should handle that correctly, because if you have a node you might click on it and besides clicking we should scroll node into viewport, check if element is overlapped by other elements and so on.
I'd say Cuprite is ideal place for this check, because node in fact exists it's just disconnected.