Move constant-time functions into a separate module

[gabor-mezei-arm]

Description

Goals (to be done in the order described here, so as to facilitate review):

• Create a new library source file and add it to the build.
• For the sake of Mbed OS, the name of the new file must be sufficiently distinctive: Mbed OS's build system does not support two .c files with the same name in different subprojects.
• Do not expose any of the new functions publicly for now. Declare them only in a header file inside library.
• Rename existing functions to have a suitable name (mbedtls_<modulename>_xxx). The names should be unique except for functions that have exactly the same prototype and interface.
• Move existing constant-time code to the new file.
• Merge functions that have the same (or nearly the same) semantics but different interfaces.
• Unify the interfaces. For example: decide whether to output 0/1 or 0/~1, to mask uint8_t or size_t.

Resolves #3649

Requires Backporting

• 2.x [Backport 2.x] Move constant-time functions into a separate module #5154

Todos

• Documentation
• Changelog updated
• Backported

[gilles-peskine-arm]

I reviewed this PR commit by commit, but since I think f0c2880 needs major rework, I've only made an architectural review for the work done in the subsequent commits. Other than the issue with rsa_private and the recommendation to delay moving base64 functions until after #4814 is fixed, I agree with the general idea of the changes made, I just haven't fully verified that they're correct.

[gilles-peskine-arm]

There is another ongoing work on the Base64 constant-time code (#4835, which I started but @tom-daubney-arm has taken over). To facilitate concurrent work on two moderately complex pull requests, I propose to leave the base64 module alone in this pull request. This way, #4835 and the 3.0 version of it can make progress. Once both this PR and the base64 PR are merged, make another simple PR to move the new base64 functions to the new module.

[gilles-peskine-arm]

pr-merge passed on 77390dc. Travis and pr-head failed only on known issues. So this PR is good to merge once the backport is ready.

[gilles-peskine-arm]

The latest run of pr-merge fails with seemingly relevant errors. Can you please investigate?

[davidhorstmann-arm]

Hmm. The failure seems to be related to a usage of mbedtls_ssl_safer_memcmp() introduced in aa5f5c1 (#4952), after this PR was created (in library/ssl_tls13_generic.c, line 905).
Rebasing or merging then changing the use of mbedtls_ssl_safer_memcmp() to use mbedtls_ct_memcmp() should fix it I believe, although a merge/rebase may not be desirable.

[mpg]

Ok, so that's a conflict (just not the kind that git can notice) so we should handle it like any other conflict and either rebase this branch on current development, or merge current development into this branch, depending on what's most convenient considering this PR's history. Labeling "needs: work" then.

[gilles-peskine-arm]

Given that this PR involves moving code and renaming functions, a rebase would be very painful. So please do a merge, then separate commit(s) to resolve the bugs.

[davidhorstmann-arm]

LGTM - thanks!