Malformed Router Advertisment packet in DHCPv6 (with patch)

### Prerequisites

- [X] I have checked the [Wiki](https://github.com/AdguardTeam/AdGuardHome/wiki) and [Discussions](https://github.com/AdguardTeam/AdGuardHome/discussions) and found no answer

- [X] I have searched other issues and found no duplicates

- [X] I want to report a bug and not ask a question

### Operating system type

Linux, Other (please mention the version in the description)

### CPU architecture

AMD64

### Installation

GitHub releases or script from README

### Setup

On one machine

### AdGuard Home version

v0.107.29

### Description

## What did you do?
I am using AdGuard for a couple DNS rewrites and as a DHCP server in order to provide AdGuard as the DNS server (my router has no options to override the DNS server). For IPv4, this worked perfectly, and my server was set as the DNSv4 nameserver. For IPv6, the router was still used as the DNS server. I used wireshark to analyze the packets and discovered that the packets are malformed due to the MAC address being padded by zeros (See images)

## Original packet:
Router Advertisement packet from Adguard. Note that the MAC address is suffixed by 2 empty bytes before the next ICMPv6 option (which is the DNS option). (MAC address has been replaced with XX)
```
0070 xx xx xx xx xx xx 00 00 19 03 00 00 00 00 0e 10
0080 fe 80 00 00 00 00 00 00 cc 88 e2 8d 78 03 44 3f
```
The packet after the Source Link-layer Address packet is then malformed since it begins with zeros.

## Edited packet:

If I edit that packet to remove those zeros, the packet is detected properly:
```
0070 xx xx xx xx xx xx 19 03 00 00 00 00 0e 10 fe 80
0080 00 00 00 00 00 00 cc 88 e2 8d 78 03 44 3f
```

## Additional information
I believe that the cause of this is [`hwAddrToLinkLayerAddr`](https://github.com/AdguardTeam/AdGuardHome/blob/master/internal/dhcpd/routeradv.go#LL43C8-L44C1) which converts MAC addresses to 8 bytes. While the RFC says that the length of the packet must be 8 bytes, I believe that is: Option Type (1 byte) + Length (1 byte) + address (6 bytes) = 8 bytes. Based on my inspection of Router Advertisement packets of my router, the address is 6 bytes. The [RFC](https://datatracker.ietf.org/doc/html/rfc4861#section-4.6.1) linked at the start of the function matches this interpretation:
```
Length The length of the option (including the type and
length fields) in units of 8 octets.
```

I have written a pull request that fixes this issue: #5841