Property-based tests for the base64 module

[Maria-12648430]

As the title says, this PR introduces property-based tests for the base64 module.

Test coverage is around ~95%, looks like some obscure edge cases that may occur in relation to mime_decode are rarely created by the generators. However, those are covered by the normal CT suite.

---

Some things I noticed while working on this:

• The decoding functions may fail in a variety of ways on malformed input. There is badarg which is fine and expected, but there is also badarith, function_clause, case_clause etc bubbling up from internal functions. This multitude of error reasons makes handling them tedious (and so, lazy as I am, I settled on catching error:_ after hitting three different error reasons). What (I guess) I'm trying to say is, they essentially all boil down to the argument being somehow bad, and so it may be good to unite them all under the badarg reason.
• mime_decode/1 and mime_decode_to_string/1, the relaxed siblings of the pedantic decode/1 and decode_to_string/1 functions, are surprisingly strict when it comes to padding, or rather missing padding. In reality (that is informally, which in turn is IMO), padding is not strictly required if you know that your input is Base64. So it may be opportune to lift that restriction for the relaxed decoding functions.

[github-actions]

CT Test Results

       2 files       85 suites   29m 58s ⏱️
1 668 tests 1 532 ✔️ 136 💤 0 ❌
1 930 runs  1 791 ✔️ 139 💤 0 ❌

Results for commit c43bac2.

♻️ This comment has been updated with latest results.

To speed up review, make sure that you have read Contributing to Erlang/OTP and that all checks pass.

See the TESTING and DEVELOPMENT HowTo guides for details about how to run test locally.

Artifacts

• Complete CT logs (Download Logs)
• HTML Documentation (Download HTML Docs)
• Windows Installer

// Erlang/OTP Github Action Bot

[bjorng]

Overall looks good to me.

The base64 module has been optimised for speed (but it is still considered too slow) and no attempt has been made to produce nice error messages. With improvements in the compiler in recent releases, it might now be possible to produce more consistent error behaviour without compromising performance, but that should be a the subject of a separate pull request.

[Maria-12648430]

@bjorng ok, I think I did all the requested changes 😃

[bjorng]

Thanks! Can you squash the commits?

We will test this PR in our daily builds after the release of Erlang/OTP 25.

[Maria-12648430]

Thanks! Can you squash the commits?

Done 👍

We will test this PR in our daily builds after the release of Erlang/OTP 25.

Ok, looking forward to it (OTP/25, too 😉)

[bjorng]

Thanks for your pull request.