Fix bulk attendance download stalling over WAN / high-latency links

[hmshb]

Problem

getAttendances() works perfectly on a LAN but truncates the bulk download to roughly the first ~2 chunks when the device is reached across the internet or any slow / high-latency link. It typically surfaces as Fetched 0 logs or only old records, with the recent punches (at the tail of the history) never arriving. This is a long-standing pain point — see node-zklib#31.

I traced it on a live ZKTeco K50 behind PPPoE, reached from a cloud server. The connection, voice test and record-count all worked; only the bulk download stalled — consistently at the same byte boundary regardless of timeout.

Root causes (in readWithBuffer)

1. All chunk requests were fired up front (for (i=0..numberChunks) sendChunkRequest(...)). On a LAN the device keeps up. Over a high-latency link the device's send buffer fills faster than the link drains, the later chunks never arrive, and the stream wedges — truncating the download.

2. The inter-packet timeout was hardcoded to 10000 ms and ignored the constructor timeout, so slow links couldn't be given more breathing room.

Changes (all backward compatible)

• Request chunks sequentially — send one chunk request, wait for it to fully arrive, then request the next. Only one chunk is ever in flight, so the slow link keeps up and the download runs to completion. This is the same approach mature implementations (e.g. Python pyzk) use.
• Respect the configured timeout for the inter-packet wait instead of the hardcoded 10s (falls back to 10s when unset).
• New optional maxChunk constructor argument (default unchanged at 65472). Lowering it (e.g. 8184) makes each chunk individually more robust on poor links.

// unchanged default behaviour:
const device = new ZKLib(ip, 4370, 10000, 5200)
// smaller chunks for a slow/WAN link:
const device = new ZKLib(ip, 4370, 60000, 5200, 8184)

Result

On the real K50 over the WAN link this was the difference between a download that stalled at ~3,200 records (months-old data) and one that pulled the full ~9,900 records including same-day punches in ~18s.

No API breakage: omit maxChunk and behaviour is identical to before. Verified against a live device; node -c clean.