DataHandle: findString(..) add support handles with unknown length

[gab1one]

• The findString(..) method used to require the exact length of the
  handle, this length can be unknown, e.g. for compressed handles.
  This is no longer the case

[ctrueden]

Just a couple of quick questions:

• How much effort would be required to add a test? If easy, please do it.
• Did you verify same performance? From the patch it does not appear there would be an issue, but good to be certain.

[gab1one]

@ctrueden regarding the testing, I encountered this bug when working on #274, there I was able to test it as well.

[gab1one]

I just cleaned the code up a bit more, now it should be more clear and length() is not used anywhere.

[ctrueden]

Thanks @gab1one, but my previous two questions still stand:

1. Would it be possible to add a regression test for findString, which failed previously, but passes now?
2. Did you do any performance checking?

[gab1one]

1. I can try building such a test, it would require a handle that reports it's length wrongly.
2. I did not, but I did not change how the actual processing logic work, basically I just moved the reading into the while loop head and used the number of read bytes as a EOF signal instead of the length reported by the handle. I can try to do some performance testing together with 1).

[ctrueden]

it would require a handle that reports it's length wrongly.

Why? I thought the issue was for handles that do not know their own length. As in: they return -1? Did I misunderstand?

I did not change how the actual processing logic work

Fair enough; let's not worry about it then.

[gab1one]

Yes ones that return -1. I added a test that reproduces the bug and discovered another one :), BytesHandle did not return -1 on EOF, see #341