openthread: OTBR cannot parse large SRP update due to fragmentation

Describe the bug SRP server on the OTBR fails to parse an SRP update that is too large to fit in a single IPv6 packet. In such a case the datagram is fragmented and the SRP server tries to process the first fragment alone which results in the following error:

May 23 11:49:09 b22caefa12ee otbr-agent[210]: 01:54:23.728 [W] SrpServer-----: Failed to process Service Discovery instructions: Parse
May 23 11:49:09 b22caefa12ee otbr-agent[210]: 01:54:23.728 [W] SrpServer-----: Failed to process DNS Update section: Parse

I checked that the failing line of code is:

SuccessOrExit(error = aMessage.Read(signatureOffset, signature));

Root cause: signatureOffset is greater than the payload length.

I’m filing an issue here instead of in the OTBR repo as I’m not sure if an SRP client should create such big updates at all or maybe they should be split into smaller ones.

To Reproduce

1. Run OTBR (OTBR SHA: bb3c1e) and form a network.
2. Build OpenThread CLI for nRF 52840 DK (OpenThread SHA: 130afd9) with OPENTHREAD_CONFIG_SRP_CLIENT_BUFFERS_MAX_SERVICES changed to 6.
3. Run the following commands on the CLI:

ifconfig up
dataset set active <otbr-dataset>
thread start
srp client autostart enable
srp client service add 0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcde _matterc._udp,_A1,_A2,_A3,_A4,_A5,_A6 12345 0 0 364b45593d7478743174787431747874317478743174787431747874317478743174787431747874317478743174787431747874317478
srp client service add 1123456789abcdef0123456789abcdef0123456789abcdef0123456789abcde _matterc._udp,_A1,_A2,_A3,_A4,_A5,_A6 12345 0 0 364b45593d7478743274787432747874327478743274787432747874327478743274787432747874327478743274787432747874327478
srp client service add 2123456789abcdef0123456789abcdef0123456789abcdef0123456789abcde _matterc._udp,_A1,_A2,_A3,_A4,_A5,_A6 12345 0 0 364b45593d7478743374787433747874337478743374787433747874337478743374787433747874337478743374787433747874337478
srp client service add 3123456789abcdef0123456789abcdef0123456789abcdef0123456789abcde _matterc._udp,_A1,_A2,_A3,_A4,_A5,_A6 12345 0 0 364b45593d7478743474787434747874347478743474787434747874347478743474787434747874347478743474787434747874347478
srp client host name hosthosthosthosthosthosthosthosthosthosthosthosthosthosthosthos
srp client host address fd11:22:0:0:a295:b6e6:a120:c3c

1. Observe that the services are never registered:

$ srp client service
instance:"3123456789abcdef0123456789abcdef0123456789abcdef0123456789abcde", name:"_matterc._udp,_A1,_A2,_A3,_A4,_A5,_A6", state:Adding, port:12345, priority:0, weight:0
instance:"2123456789abcdef0123456789abcdef0123456789abcdef0123456789abcde", name:"_matterc._udp,_A1,_A2,_A3,_A4,_A5,_A6", state:Adding, port:12345, priority:0, weight:0
instance:"1123456789abcdef0123456789abcdef0123456789abcdef0123456789abcde", name:"_matterc._udp,_A1,_A2,_A3,_A4,_A5,_A6", state:Adding, port:12345, priority:0, weight:0
instance:"0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcde", name:"_matterc._udp,_A1,_A2,_A3,_A4,_A5,_A6", state:Adding, port:12345, priority:0, weight:0

Expected behavior Successful registration of the services.

Console/log output Already provided above.

Additional context Building OTBR with OT_IP6_FRAGM enabled solves the issue, because then the fragmented datagram is reassembled on the OTBR side.