This is a follow-up PR to GH-24402.

Currently, *base64.b64decode* uses a generic regex to validate *s* (when *validate* is true),
which sometimes results in unexpected behavior and exception messages.

Example:

(1)    base64.b64decode('ab==',  validate=True) # b'i'
(2)    base64.b64decode('ab3==', validate=True) # b'i\xbd'
(3)    base64.b64decode('ab=3=', validate=True) # raises binascii.Error: Non-base64 digit found
(4)    base64.b64decode('ab==3', validate=True) # raises binascii.Error: Non-base64 digit found
(5)    base64.b64decode('ab===', validate=True) # raises binascii.Error: Non-base64 digit found
(6)    base64.b64decode('=ab==', validate=True) # raises binascii.Error: Non-base64 digit found

The only strict-base64 valid example here is (1).
(2), (4) and (5) should raise 'Excess data after padding',
(3) should raise 'Discontinuous padding not allowed',
and (6) should raise 'Leading padding not allowed'.

To get this behavior, we can use the new (at the time of creating this PR) *binascii.a2b_base64* functionality of strict mode.

I have one (not so big) concern - efficiency.
I'm not that experienced with how fast regex-es are (in Python or in general) compared to the implementation of *binascii.a2b_base64* in C.
So, I've no idea what would be the impact of migrating from regex pre-validation to input parsing.
Let me know if you find it inefficient.

-----

Referenced issue (GH-24402): https://bugs.python.org/issue43086

I'm not worried about the regex vs binascii C implementation performance at all.

New changeset fa6304a5225787054067bb56089632146d288b20 by Idan Moral in branch 'main':
bpo-44690: Adopt binacii.a2b_base64's strict mode in base64.b64decode (GH-27272)
https://github.com/python/cpython/commit/fa6304a5225787054067bb56089632146d288b20