When Redis is enabled, we want to cache the markdown processing for post pages (and any other pages that require markdown?) to enable server-side rendering without the massive latency caused by this logic.

This ticket involves adding the redis client and creating a version of getMarkdownHtml (getPostHtml?) that takes in a post slug instead of a file path and caches its response (if redis is configured).

Redis will not be enabled for static builds or in local dev - in this case, it should continue to function as normal.

Overview of the expected post request:

• user requests the post route
• the Astro page is invoked & is passed the locale & post slug params from the URL
• it calls getPost (which in the future would go to hoof and get metadata returned, including a hash & URL to the markdown contents on S3 - see: Endpoint for get post by ID hoof#80)
• it calls getMarkdownHtml, which would look at the post slug, locale, hash (returned from hoof), and version (see below) to see if it's in the redis cache
  • if yes, getMarkdownHtml returns the cached component tree
  • if not, getMarkdownHtml downloads the markdown from S3 and builds the playful component tree, then stores it in the cache
• the component tree is then rendered in the page

We need a way to invalidate old cache entries whenever new changes to the markdown processing (e.g. a new component attribute) are deployed. This can be done by adding a "release version" to each key.

This should likely be automated + passed in as a build arg.