fix: multichunk reads

[SirBrucey]

When EPP responses arrived in multiple chunks, the read counter would reset to its previous value instead of accumulating.
This caused the code to think it hadn't read as many bytes as it actually had, leading to "Unexpected EOF while reading" errors.

2026-02-05T12:02:05.416810Z DEBUG: instant_epp::connection: Expected response length: 2539
2026-02-05T12:02:05.417597Z DEBUG: instant_epp::connection: Read 1172 bytes, 1428 out of 2539 done
2026-02-05T12:02:05.417637Z DEBUG: instant_epp::connection: Read 1111 bytes, 1367 out of 2539 done

The connection state machine's pattern destructuring creates copies of state fields instead of mutable references into the struct. When these were modified (e.g., incrementing read counter), the modifications were lost because the original state was returned.

Example:

RequestState::Reading { mut read, buf, expected } => {  // copies read
  ...
  read += filled.len();  // Modifies LOCAL copy
  ...
  Transition::Next(state)  // Returns ORIGINAL state with OLD read value
}

Fix: Construct new state objects with updated values:

RequestState::Reading { read, buf, expected } => {
  let new_read = *read + filled.len();  // Calculate new value

  // Return NEW state with updated counter
  Transition::Next(RequestState::Reading {
      read: new_read,
      buf: mem::take(buf),
      expected: *expected,
  })
}

[djc]

Nice, thanks for fixing this upstream and adding test coverage!

Would be curious to hear what/where you're using it.

[SirBrucey]

Sorry for the delay, those fixes have been pushed up.

Would be curious to hear what/where you're using it.

I am currently trying to use the library to talk to nominet

[djc]

Some minor nits, please also squash all of your commits.

[djc]

Okay, some minor remaining nits: please order these in top-down fashion; first the #[test] functions, then connect_with_chunks(). Suggest inlining len_bytes() and changing greeting to be a const (this should be at the bottom).

[SirBrucey]

nits addressed and squashed.

[valkum]

I encountered this approx. at the same time and would have filed a PR fixing this if I had not found this PR at the time. Could we move this forward so I can drop my own fix.
If you want, I can take care of the remaining remarks next week. Just not sure about the best way to do so. Should I send you a patch, create PR with existing commits and mine on top, or something different?

[djc]

Send your own PR with a clean commit history, keep the author of this PR as author or co-author of commits where that makes sense.

[SirBrucey]

I encountered this approx. at the same time and would have filed a PR fixing this if I had not found this PR at the time. Could we move this forward so I can drop my own fix. If you want, I can take care of the remaining remarks next week. Just not sure about the best way to do so. Should I send you a patch, create PR with existing commits and mine on top, or something different?

Apologies I missed the above response. I'll get those changes in today.

[valkum]

Apologies I missed the above response. I'll get those changes in today.

Thank you!