Base 64 decoder, reject input when unused bits are not 0

[buyaa-n]

When the input is not multiple of 3 some bits of the encoded values are not used, Base64 encoder sets those bits to 0, but decoder currently doesn't check those bits and allows any combination of values. Therefore multiple input could decoded to same value, for example when the input is 1 byte character 'A', encoder encodes it to 2 base64 characters and 2 padding "QQ==" , the last 4 bits of the 2nd Q is not used and set to 0s, but decoder doesn't validate that and allows 2^4 = 16 values decoded into same value, for example: "QQ==", "QR==", "QS==", "QT==", "QV==", "QU==", "QW==", "QX==", "QY==", "QZ==", "Qa==", "Qb==", "Qc==", "Qd==", "Qe==", "Qf" will be decoded to a same value, 65, ascii of 'A'.

The spec mentions that unused bits MUST be set to zero by conforming encoders. It also mentions that decoders may reject an input if pad bits have not been set to zero. We don't see any reason to keep allowing non-zero value for those other combinations that produce same result when encoders are expected to produce only one value.

This doesn't seem to be a breaking change, my quick research did not find any encoder, that produces output that doesn't set unused bits to 0. Though it could break tests that randomly generates Base64 encoded text.

Further we should fix this for Convert.FromBase64XYZ(...) overloads

Related to #50233 (comment)

[dotnet-policy-service]

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