Update MaxMessageLength behavior

[ltpquang]

This PR intends to update goadb's behaviors regarding to message length. So that:

• Accept all message lengths returned from adb server
• Update MaxMessageLength and length-checking logics to reflect current adb's implementation

This fixed #31, and (hopefully) #26 #29.

Please take a look @zach-klippenstein. Thanks!

[ltpquang]

@zach-klippenstein hi there any progress on this?

[zach-klippenstein]

Given the above comment, there should also be an explanation where this number comes from.

[ltpquang]

Good point, I've just updated the comment. Also, I renamed MaxMessageLength to MaxPayloadSize for better reflecting adb's implementation.

[zach-klippenstein]

Why -4?

[ltpquang]

A message's payload is combined from:

1. 4-byte hex string denoting message's length
2. The message itself

The ADB's implementation implies that the MaxPayloadSize is the size of the message AND the length-string:

MaxPayloadSize = MessageLenghtStringSize + MaxMessageLength

Therefore we need to minus 4 bytes (length-string) to get the message's size.

[ltpquang]

Hi @zach-klippenstein any update on this PR?

[evrins]

please merge this pr.
the limit of 255 bytes on response body size may make ListDevices function panic on parseKeyVal.
because response may trunk making parse fail.
eg:
full response:

24bc6ecc               device product:T782H_EEA model:T782H device:Boston transport_id:8
62bf3267               device product:T782H_EEA model:T782H device:Boston transport_id:7
99384216               device product:T782H_EEA model:T782H device:Boston transport_id:5
abef8bde               device product:T782H_EEA model:T782H device:Boston transport_id:6
f7241975               device product:T782H_EEA model:T782H device:Boston transport_id:4

trunked response:

24bc6ecc               device product:T782H_EEA model:T782H device:Boston transport_id:8
62bf3267               device product:T782H_EEA model:T782H device:Boston transport_id:7
99384216               device product:T782H_EEA model:T782H device:Boston tra

parseKeyVal panic on tra

[webninjadk]

still is not merged?

[aac3476]

why not merged?
if we have too many device it will panic

[asjdf]

Looking forward to this PR being merged