Always tamper the signature in the data area

When tests such as System.Security.Cryptography.X509Certificates.Tests.RevocationTests.DynamicRevocationTests.RevokeEndEntityWithInvalidRevocationSignature ran on EC-DSA with secp384r1, there is a roughly 50% chance that flipping all of the bits in signature[5] will produce a signature value that is not structurally valid DER by making the first 9 bits of an INTEGER all have the same value.

OpenSSL bubbles up this error differently from "it is structurally valid, but the signature is wrong", which makes our tests fail.

While there is some value in making these sorts of tamper look the same on Windows and Linux, the most important tamper is "the data was tampered with, invalidating the unchanged signature".  That's the scenario these tests are trying to test (by making the signature wrong), so instead do the tamper at the second-to-last byte of the signature, which is always going to be in the "data" segment of a signature, never "structure" (for any known algorithm).

Author: bartonjs

src/libraries/Common/tests/System/Security/Cryptography/X509Certificates/CertificateAuthority.cs

@@ -488,7 +488,7 @@ private byte[] BuildCrlManually(
 
             if (CorruptRevocationSignature)
             {
-                signature[5] ^= 0xFF;
+                signature[^2] ^= 0xFF;
             }
 
             // CertificateList
@@ -643,7 +643,7 @@ certs            [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }
 
                     if (CorruptRevocationSignature)
                     {
-                        signature[5] ^= 0xFF;
+                        signature[^2] ^= 0xFF;
                     }
 
                     writer.WriteBitString(signature);