aws-lc: do not use large buffer

[icing]

test_10_08, uploading larger files for a h2 proxy, sporadically fails with a decrpytion error on received data in AWS-LC. The frequency can be increased by simulated network receive blocks.

Not setting a 4 * TLS record sized buffer, leaving AWS-LC at its default buffer size seems to mitigate this problem.

[vszakats]

This feature has been disabled for BoringSSL since the original
commit, though for a different reason. I suggest merging the
exclusion with AWS-LC and move the comment there to explain
the reasons. To join these two build variants and simplify a bit:

--- a/lib/vtls/openssl.c
+++ b/lib/vtls/openssl.c
@@ -121,8 +121,12 @@
 static void ossl_provider_cleanup(struct Curl_easy *data);
 #endif
 
+/* BoringSSL is missing this API.
+   AWS-LC seems to run into decryption failures with large buffers.
+   Sporadic failures in test_10_08 with h2 proxy uploads, increased
+   frequency with CURL_DBG_SOCK_RBLOCK=50. */
 #if OPENSSL_VERSION_NUMBER >= 0x10100000L && \
-  !defined(LIBRESSL_VERSION_NUMBER) && !defined(OPENSSL_IS_BORINGSSL)
+  !defined(LIBRESSL_VERSION_NUMBER) && !defined(HAVE_BORINGSSL_LIKE)
 #define HAVE_SSL_CTX_SET_DEFAULT_READ_BUFFER_LEN 1
 #endif

Added to AWS-LC via:
aws/aws-lc@0fb67dd
aws/aws-lc#1517

[icing]

This feature has been disabled for BoringSSL since the original commit, though for a different reason. I suggest merging the exclusion with AWS-LC and move the comment there to explain the reasons.

Agreed, done.

[vszakats]

Suggested change

	!defined(LIBRESSL_VERSION_NUMBER) && !defined(OPENSSL_IS_BORINGSSL) && \
	!defined(OPENSSL_IS_AWSLC)
	!defined(LIBRESSL_VERSION_NUMBER) && !defined(HAVE_BORINGSSL_LIKE)

HAVE_BORINGSSL_LIKE covers both BoringSSL-like backends (in lib/vtls), added in: 0be7f38

Save a couple exceptions these two backends use the same codepath in curl.

[bagder]

Since it is disabled for different reasons for the two libraries, maybe keeping the conditions for both makes it easier to change one of them if their individual condition changes?

[vszakats]

It can be done when they will be different in the future IMO.

[icing]

Since the disable is for different reasons, I think checking the separate defines is better for maintenance.