Add test coverage for DirectoryServices.TransformControls

[edwardneal]

Relates to PR #101512.

This PR introduces test coverage for DirectoryServices.TransformControls. The method parses five types of control - AsqResponseControl, DirSyncResponseControl, PageResultResponseControl, SortResponseControl and VlvResponseControl.

Each control splits the parsing attempt into three groups:

• Conformant: values which conform to the relevant spec, and which we expect to pass.
• Invalid: various combinations of poorly-structured values. These should always fail with a BerConversionException.
• Nonconformant: values which aren't spec-compliant, but which are parsed anyway because BerConverter is forgiving.

These tests pass on my Windows PC, with different handling for OpenLDAP and earlier versions of Windows. There are a few interesting variations.

Platform variations

• Windows mandates that a SEQUENCE's length completely covers the length of its contents. An OCTET STRING with a length which extends beyond the length of its containing SEQUENCE will fail to parse. OpenLDAP does not implement this restriction - if the OCTET STRING overruns the SEQUENCE, it'll be parsed and returned.
• On versions of Windows prior to Windows 10, when a zero-length OCTET STRING is parsed as a string (format specifier of a) it will return null. After Windows 10 and in OpenLDAP, it returns a zero-length string. This is a behavioural difference between .NET and .NET Framework (which always returns an empty string.)
• OpenLDAP seems to validate a BER element's tag, where Windows does not. If BerConverter expects to find an optional OCTET STRING but actually encounters trailing bytes, OpenLDAP will return null but Windows will return an empty string.
  • I expect this is because the trailing bytes' values are 0x80. Windows treats this as a length, where bit 7 is set (indicating a long-form length) and bits 0-6 are zero (indicating that the next zero bytes of the buffer contain the length.)

Errata

If an OCTET STRING contains a trailing 0x80 byte which is an invalid Unicode character, BerConverter won't handle the DecoderFallbackException - that exception will just bubble up to the caller. There's a test to verify this behaviour, but I'm pretty sure this is a bug.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-directoryservices, @jay98014
See info in area-owners.md if you want to be subscribed.

[buyaa-n]

Each control splits the parsing attempt into three groups:

Thank you @edwardneal looks its covered scenarios well, overall the PR LGTM

Errata

If an OCTET STRING contains a trailing 0x80 byte which is an invalid Unicode character, BerConverter won't handle the DecoderFallbackException - that exception will just bubble up to the caller. There's a test to verify this behaviour, but I'm pretty sure this is a bug.

Not sure if we should fix it or leave it as is, tag @bartonjs @jay98014 @steveharter @kumarravik78c for opinions about this

[buyaa-n]

Thank you @edwardneal

[buyaa-n]

Errata

If an OCTET STRING contains a trailing 0x80 byte which is an invalid Unicode character, BerConverter won't handle the DecoderFallbackException - that exception will just bubble up to the caller. There's a test to verify this behaviour, but I'm pretty sure this is a bug

We can fix this later if needed, going to merge this PR to unblock #101512.

[edwardneal]

Thanks @buyaa-n; I can see that my tests passed, so I'll merge into the other PR and re-test in the next few days.