Optional assume role in raster-api for external S3 bucket read permissions

[anayeaye]

What

• Optional DELTA_RASTER_DATA_ACCESS_ROLE_ARN will be assumed by raster api to obtain credentials with GetObject permissions for internal and external S3 buckets. This is intended to support reading data from external data providers that are willing to add a limited read only bucket policy to the VEDA raster api data access role.
• Catch up to IMPACT fork of eoAPI to add datasetparams and post processing functionality to the raster-api (this will allow the raster-api to support pre-defined multi band algorithms for map layers like HLS SWIR--see this explanation in a delta-config project discussion.
• Raster-api GDAL, logging, and resource configuration changes for experimenting with the raster-api (Tune raster-api config #54 removes these temporary changes when stack is operational).

Why

The raster-api needs to stream cloud optimized data from externally hosted buckets. This PR adds the methods needed to assume a role with read permissions for external buckets.

How tested

• Deployed test and dev stacks with a data access role created to enable the raster api to stream data from internal and external buckets that have policies permitting that role to GetObjects.
• Confirmed that only gdal debug configuration changes are deployed if optional data access role arn is not provided.
• Confirmed that the eoAPI post processing methods work in a us-west stack with manually inserted HLS credentials

Notes:
(1) This PR adds logging that we will not want to keep for the long term; issue #54 reminds us to revisit the raster-api configuration and scale back logging and tune GDAL settings.
(2) Earlier versions of this branch included an external edl-credential-rotation service to obtain earthdata credentials on behalf of the raster api. Credential rotation may be added in future development but this PR only adds the option to assume a role in the raster api for external s3 data access.

[anayeaye]

I stamped this with an ominous 'do not merge' message but the changes themselves are non-breaking. The raster api works as expected when the session tokens are removed from the raster-api environment. The issue only comes up if the edl service is running and adding session tokens to the raster api environment.

[leothomas]

Looks good to me! I'm curious where the value for GDAL_HTTP_RETRY_DELAY comes from. Seems very specific

[anayeaye]

Looks good to me! I'm curious where the value for GDAL_HTTP_RETRY_DELAY comes from. Seems very specific

I took this (and all or the raster-api updates) from the IMPACT eoAPI but I don't know how @sharkinsspatial and @vincentsarago chose that very specific value. I added a note to the tech debt issue #54 that we should try to explain or remove this setting.