Update the base64 encoder padding to match the spec

[chuff]

No description provided.

[pgoforth]

This is needed for spec compatibility because one base64 character represents 8-bits of data.

[HeinzBaumann]

What you say is to not do this change (PR) at all. This is the only change to code. All other changes update the test cases.

[pgoforth]

Please tell my why this change is necessary.

If you start encoding using only % 6 for padding, you will create a misaligned byte string upon decoding when you use this for TCF strings (which GPP is also responsible for).

This is fine if you are reading/writing using ONLY this library, but you are creating a GPP string that is going to be read and decoded by multiple third party decoders that expect a valid byte[]. Using only % 6 creates a misaligned byte array that would be considered invalid by many other decoders.

GPP requires alignment on 6 bits:
https://github.com/InteractiveAdvertisingBureau/Global-Privacy-Platform/blob/main/Core/Consent%20String%20Specification.md#creating-a-gpp-string

TCF requires alignment on 8 bits. This requirement has never been altered since v1.1 and there has been no reference to a change in any TCF updates:
https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework/blob/10b489eae0d5328e07241001520d984e15afb59a/Consent%20string%20and%20vendor%20list%20formats%20v1.1%20Final.md?plain=1#L316

Therefore, padding to the LCM of 8 and 6 is necessary (LCM=24 because 6*4=24 and 8*3=24).

Since this is a common encoder/decoder, it is used for both TCF and other GPP represented strings. Simply forwarding the TCF portion of the string to a TCF decoder would produce an error if the encoder only padded using 6 bits.

[HeinzBaumann]

What you say is to not do this change (PR) at all. This is the only change to code. All other changes update the test cases.