Fix data corruption/mangling in DeviceCommissioner::SendOperationalCertificate

[bluebin14]

Problem

What is being fixed?

• fixes TODO in DeviceCommissioner::SendOperationalCertificate, which was corrupting the op cert and failing to send the ICA cert
• Fixes Fix data corruption/mangling in DeviceCommissioner::SendOperationalCertificate #6877

Change overview

What's in this PR

DeviceCommissioner::SendOperationalCertificate now correctly sends both the op cert and the ICA cert. Previously it was corrupting them both, thinking that TempZCL protocol needs to be supported which has a 255 byte limitation. TempZCL protocol is not involved here, the code uses Interaction Model exclusively which ends up in OperationalCredentialsCluster::AddOpCert which already does the right thing when the byte span is larger than 255 bytes.

Testing

How was this tested? (at least one bullet point required)

• tested manually by sending more than 255 bytes per certificate and verifying the following:
• certs are not split (previously op cert was split)
• both certs are sent (previously ica cert was ignored)

[yunhanw-google]

@pan-apple please take a look, thanks

[pan-apple]

@bluebin14 , thanks for putting up the PR. I think we should also update the code in the following function. That's the server side, which has the logic to reassemble the split certificate. Even though the current code will work, but eventually we'll send ICA certificates as well. That'll break the flow, as it'll try to combine the op cert and ICA cert buffers.

bool emberAfOperationalCredentialsClusterAddOpCertCallback(chip::app::Command * commandObj, chip::ByteSpan NOC,
                                                           chip::ByteSpan ICACertificate, chip::ByteSpan IPKValue,
                                                           chip::NodeId CaseAdminNode, uint16_t AdminVendorId)
```

[bluebin14]

@pan-apple yes, right now the server side is not affected by this change even though the server indeed does strange things: if ica is used (eventually) then emberAfOperationalCredentialsClusterAddOpCertCallback combines the 2 certs into an unparseable tlv and passes the blob as 1 certificate to SetOperationalCert which will of course fail. It seems there are lot of todo's there. This here only removes the imaginary 255 byte limitation on the client side.