feat: Support explict modes for read fallbacks and caching

[ethenotethan]

Fixes Issue

Fixes NA

Changes proposed

TLDR Modularized storage backend providers to allow for easy addition in the future. Additionally added explicit support for optional read fallback and caching that allows a user to construct custom configurations of proxy based on their individual risk tolerance / requirement for decentralization. E.g, I'm a customer and want caching with redis and read fallback with S3 - I can now do that (excluding redis cuz we haven't implemented yet).

Verbose Summary

• Two interfaces to differentiate between storage backends
• Modularized routing logic to easily support the addition of new backend types in the future
• Support caching mode which takes in list of supported backend storage strings (i.e, read before referencing eigenda)
• Support fallback mode which takes in list of supported backend storage strings (i.e, read only when eigenda cannot be read from)
• Extended E2E tests to verify both system flows
• Extended config rep and added tests for verification

Screenshots (Optional)

Note to reviewers

We can probably create a definition object for each storage backend to describe its allowed modes but this likely isn't necessary unless we envision support for 10+ backends with additional secondary modes outside of read-fallback, cache. We could also support many instance configurations (e.g, a separate S3 bucket for caching vs. fallback) if this is something that customers want down the line. All sensitive flows should be tested, but please review diligently.

NOTE: This PR also allows us to scale memstore in the future as well. E.g, if we have redis we can configure it as a read-fallback target when doing node development to ensure we can still reference old memory state after rebooting the proxy instance.

[samlaf]

LGTM. added some small nits