chore: require icechunk >=2.1

[maxrjones]

Summary

This PR bumps the minimum Icechunk version to >=2.1. Icechunk 2.1 added support for attaching custom HTTP headers to object-store requests, which allows using titiler-multidim with EDL. This PR is a minimal dep bump which will setup later feature PRs for HTTP schemes.

Testing

I ran the test suite, and manually tested with a virtual Icechunk store pointing to NASA tempo data (using these changes + some that will fit in follow up PRs).

PR checks

• Standard CI runs automatically on each push.
• To run the CDK synth check, add the run-cdk-checks label to this PR.
• If you push more commits after that run completes, remove and re-add the label to run it again.
• To trigger a dev deployment, add the deploy-dev label. It smoke-tests tiles from the native MUR, virtual MUR, and virtual NLDAS Icechunk stores after deployment.

[hrodmn]

@maxrjones thanks for opening the PR. To get the last CI check to pass you just need to add the run-cdk-checks label which will kick off the slow CDK build test.

[maxrjones]

@maxrjones thanks for opening the PR. To get the last CI check to pass you just need to add the run-cdk-checks label which will kick off the slow CDK build test.

The CDK tests don't pass because the env variables aren't available for workflows run from my fork. A few options solve this are:

1. override the failure and merge
2. re-open the PR from a branch inside the repo rather than my fork
3. change the workflow to trigger on pull_request_target rather than pull_request, adding an approval requirement for workflows to run to reduce exposure risk.

Do you have a preference?

[hrodmn]

ah, sorry for the turbulence on that. I'm ok with just merging this one but if there is a way to make that workflow approvable for PRs from forks then that would be a nice feature to add.

[maxrjones]

ah, sorry for the turbulence on that. I'm ok with just merging this one but if there is a way to make that workflow approvable for PRs from forks then that would be a nice feature to add.

that sounds good, I can work on that. I think it'd be good to have very minimally scoped role for this (just cdk synth, no actual deploy). Is it alright for me to set up those roles in the same AWS account for the updated workflow?

[hrodmn]

The cdk-checks workflow uses an actual account id but we should be able to just do that with dummy values. let's plan on making that workflow completely anonymous and not pulling from our deployment env vars.