Spike: HTTP 408 Request Timeout when using MARC search query

Timebox: up to 5 days

Overview: When using the SRS MARC query endpoint on environments with a large collection of SRS records, certain queries will timeout behind the scenes and return incomplete result sets.
Steps to Reproduce:

1. Using the REST client of your choice, submit a query for all SRS records in Iris bugfest environment with an OCLC identifier (POST to https://okapi-bugfest-iris.folio.ebsco.com/source-storage/stream/marc-record-identifiers):

{
  "fieldsSearchExpression": "035.a ^= '(OCoLC)'"
}

1. Wait for the response to return (~7 minutes)

Expected Results: A complete and valid response with a list of UUIDs for all Instances that match the query, and a response in under 1 minute.
Actual Results: An incomplete and invalid JSON response with an open-ended records array.
Additional Information: We can reproduce this on our Iris HF#1 environment at Cornell where we have access to the application logs. Closer inspection reveals an HTTP 408 reported by mod-aes, ~60 seconds after the initial request:

10.23.40.16 - - [09/Jun/2021:13:43:06 +0000] "POST /mod-aes/source-storage/stream/marc-record-identifiers HTTP/1.1" 408
 0 rt=60.000 uct="-" uht="-" urt="-" "insomnia/2021.3.0" "fs00001034" 
"3354c674-a7c9-403d-8fc1-8cbc20f3ae76" "813530/source-storage"

Could we be hitting the default timeout for AWS load balancers? Is this reproducible in environments where mod-aes is not installed/enabled?
Interested parties: jenncolt, kgambrell, Igor_Gorchakov, mreno, hji