Fix DHCPv4 panic when T1 < T2 < lease duration is not respected

[thvdveld]

This is an attempt to try fixing #1028. I'm not sure if this is the correct approach. When invalid values for T1 and T2 are received, default values are calculated instead. Maybe the ACK should be ignored instead of using default values?

If using default values is the approach we want, then this PR should still add tests.

Fixes #1028

[codecov]

Codecov Report

Attention: Patch coverage is 25.00000% with 6 lines in your changes missing coverage. Please review.

Project coverage is 80.88%. Comparing base (3a30d0c) to head (e77d02b).
Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
src/socket/dhcpv4.rs	25.00%	6 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1029      +/-   ##
==========================================
- Coverage   80.89%   80.88%   -0.01%     
==========================================
  Files          81       81              
  Lines       28448    28452       +4     
==========================================
+ Hits        23012    23013       +1     
- Misses       5436     5439       +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[whitequark]

Seems reasonable to me. There isn't much more we can do against a malicious or broken DHCP server.

[whitequark]

Maybe the ACK should be ignored instead of using default values?

We could do that, but (assuming a genuinely broken server) debugging IP assignment failures is always really unpleasant, so accepting it feels like the right choice.

[Dirbaio]

yeah, accepting it will most likely result in everything working fine (DHCP servers usually tolerate clients renewing/rebinding earlier/later than expected), while ignoring it will most likely result in things not working at all. Retrying likely won't fix it since the server is probably consistently misconfigured/buggy.

[whitequark]

Oh, merged with no tests...