Resolve issue with openssl 3.5.3 encrypt

[mdlowman]

PLEASE NOTE the following text from the iperf3 license. Submitting a
pull request to the iperf3 repository constitutes "[making]
Enhancements available...publicly":

You are under no obligation whatsoever to provide any bug fixes, patches, or
upgrades to the features, functionality or performance of the source code
("Enhancements") to anyone; however, if you choose to make your Enhancements
available either publicly, or directly to Lawrence Berkeley National
Laboratory, without imposing a separate written license agreement for such
Enhancements, then you hereby grant the following license: a non-exclusive,
royalty-free perpetual license to install, use, modify, prepare derivative
works, incorporate into other computer software, distribute, and sublicense
such enhancements or derivative works thereof, in binary and source code form.

The complete iperf3 license is available in the LICENSE file in the
top directory of the iperf3 source tree.

• Version of iperf3 (or development branch, such as master or
  3.1-STABLE) to which this pull request applies: master

• Issues fixed (if any):

1. Setting the output buffer size fixes authentication on openssl 3.5.3.
2. While I was looking at the code, also fixed a small out-of-bounds access on base64 decoding.
3. Renamed keysize to output_buffer_len to be clearer.
4. Replaced some allocations of larger buffers; the larger allocations did not affect correctness, but made the code harder to follow.
5. Added a warning when data was silently truncated. Makes no difference to the caller, but makes it more obvious that there is no chunking of input material and that the plaintext is capped at the number of bits of the encryption.

Only the first commit is necessary to resolve the issue with openssl 3.5.3.
If you prefer to accept only a subset, or to consider them in separate pull requests, I can edit this/open others.

• Brief description of code changes (suitable for use as a commit message):

Set output buffer size prior to encrypt operation
When calling EVP_PKEY_encrypt with a non-null output buffer,
the output buffer length must be provided. Attempts to write
beyond this length will fail.

Rename keysize to output_buffer_len
This more accurately represents the meaning; it is the minimum
buffer allocation necessary for an encrypt or decrypt operation
to succeed. This is the same size for both ciphertext and
cleartext, as padding is applied.

Avoid out-of-bounds access when base64 decoding short strings
Check the length before reading memory.

Don't over-allocate followed by partial reads
We know how much we expect to read; the input buffer
has a defined size. Allocate the exact buffer expected
instead of a larger one with a read expected to return
only partial data. This makes it simpler to follow the
logic and to avoid off-by-one errors.

Add warnings on silent truncation
Input should not be this long, but makes the expectations
of the code clearer.

[swlars]

Looks good! Thank you for the pull request!