Fix IPv6 extension header length calculation in dhcp6relay

[xq9mend]

Why I did it

The IPv6 extension header parsing loop in dhcp6relay advances the current position by the raw ip6e_len byte value. Per RFC 2460/8200, ip6e_len is in units of 8 octets, not counting the first 8 bytes, so the correct advance is (ip6e_len + 1) * 8. Using the raw value causes header misparse for any packet with nonzero ip6e_len, which can lead to incorrect DHCPv6 relay behavior or process crash from L2-adjacent hosts.

How I did it

Replace the raw byte advance with the RFC-mandated formula:

current_position += (ext_header->ip6e_len + 1) * 8;

Add a unit test covering the nonzero ip6e_len case (Hop-by-Hop extension header with ip6e_len=1, which should advance 16 bytes). The existing tests only covered ip6e_len=0, which was partially mitigated by a separate guard.

How to verify it

cd src/dhcprelay/dhcp6relay && make test
[==========] 46 tests from 10 test suites ran.
[  PASSED  ] 46 tests.

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[xq9mend]

@Blueve @cshivashgit