Feat/cmr support

[abarciauskas-bgse]

This PR updates the previous attempt to integrate CMR endpoints in #714

There are still some workarounds made since:

1. The CMR STAC metadata doesn't have the is_periodic or time_density fields, so we need to set this in the config file
2. The CMR STAC temporal metadata sometimes has a null trailing value to indicate ongoing datasets.
3. We need to replace the HTTPS URLs in the STAC asset links with S3 URLs.

@hanbyul-here let's discuss the options for merging this or alternative solutions - such as CMR-specific dataset + layer modules or longer term changes.

[netlify]

✅ Deploy Preview for veda-ui ready!

Name	Link
🔨 Latest commit	4504fc2
🔍 Latest deploy log	https://app.netlify.com/sites/veda-ui/deploys/65947e78f7b1150008770c3e
😎 Deploy Preview	https://deploy-preview-782--veda-ui.netlify.app/
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[hanbyul-here]

I have some questions!

I thought we want to move towards putting more metadata on the backend. It is not a big lift on the UI side to add more properties but having is_periodic time_density seems to go against the direction.

Is there a way to differentiate temporal data being intentionally null compared to accidentally null? The temporal metadata has been missing (accidentally) in the past. It will be difficult if the same null value indicates different things.

Re: Replacing HTTPS URLs in the STAC asset links with S3 URLs - is there any way to get this information dynamically? If not, it might be better to make this a property in mdx.

[abarciauskas-bgse]

@hanbyul-here thanks for looking -

1. Regarding temporal parameters - since we are pulling metadata from CMR STAC (or more specifically, https://cmr.earthdata.nasa.gov/cloudstac/GES_DISC) we cannot control the metadata that is defined there, that is why in the long term we should move to integrating with CMR directly. I was thinking that was out of scope for now since we may be doing a larger redesign + implementation of veda-ui. Your question was "Is there a way to differentiate temporal data being intentionally null compared to accidentally null" - I think the answer is maybe? If we want to build logic which distinguishes between data in our VEDA STAC catalog (accidentally null), which we control, and data in other STAC catalogs (intentionally null). I imagine that is using the same conditional as const stacApiEndpointToUse = stacApiEndpoint ?? process.env.API_STAC_ENDPOINT; to determine if we permit null temporal parameters (time_density and is_periodic). Do you think we should use this conditional to determine if null time_density and is_periodic is allowed?
2. I have made some changes to pull asset url replacements from mdx, but perhaps we could pair on it so I make those changes the best way possible.

[hanbyul-here]

I rebased main branch and opened a new pr based on this pr: #805