Add relaxed padding setting to the nclient4

[Bogdan-Denisenko]

RFC 2132 says:
The end option marks the end of valid information in the vendor field. Subsequent octets should be filled with pad options.

But it seems that this does not mean that the client should consider packages with non-pad options after the End option invalid, because RFC 2119 explains:
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

So we need a way to accept packets not padded with zeros.

[Bogdan-Denisenko]

@pmazzini review required

[codecov]

Codecov Report

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

Project coverage is 73.83%. Comparing base (bf3278a) to head (475cd0f).
Report is 2 commits behind head on master.

Files	Patch %	Lines
dhcpv4/nclient4/client.go	16.66%	5 Missing ⚠️
dhcpv4/dhcpv4.go	66.66%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #543      +/-   ##
==========================================
+ Coverage   73.77%   73.83%   +0.05%     
==========================================
  Files          81       81              
  Lines        5122     5141      +19     
==========================================
+ Hits         3779     3796      +17     
- Misses       1200     1202       +2     
  Partials      143      143              

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

[pmazzini]

I am not sure if we should make this an optional parsing or if it should make it the default one. cc @hugelgupf

[Bogdan-Denisenko]

I am not sure if we should make this an optional parsing or if it should make it the default one. cc @hugelgupf

Yes, I think it makes sense to make this behavior the default. I made it optional just to avoid changing the behavior of the exported functions.

[pmazzini]

I made it optional just to avoid changing the behavior of the exported functions

Which functions? What is the benefit of having 2 behaviors?

[Bogdan-Denisenko]

Which functions? What is the benefit of having 2 behaviors?

Functions dhcp4.FromBytes() and dhcp4.Options.FromBytes(). In my opinion it's better to just remove the check for zero-padded packets or at least make such behavior default, because it seems that such packets should be considered valid according to RFC and I don't see any benefits from the possibility to consider such packets invalid. But this would change the behavior of exported (public) functions. Is it consistent with the backward compatibility policy of this project?

[Bogdan-Denisenko]

@pmazzini Opened alternative PR with zero padding checking disabled by default - #545.

[pmazzini]

Continuation in #545