Clear the static content database cache nightly of old files

- Add `created` and `modified` fields to `RenderedContent` models
- Add caching and RenderedContent docs
- Change cache key for library description rendered content
- Add `CLEAR_STATIC_CONTENT_CACHE_DAYS` setting
- Add manager method and task to clear static content cache
- Move task scheduler to main app
- Add daily task to clear rendered content cache
- Use created date and not updated date

docs/README.md

@@ -1,6 +1,7 @@
 # Documentation for the Boost Website
 
 - [API Documentation](./api.md) - We don't have many API endpoints, but the ones we do have are documented here
+- [Caching and the `RenderedContent` model](./caching_rendered_content.md)
 - [Dependency Management](./dependencies.md)
 - [Development Setup Notes](./development_setup_notes.md)
 - [Environment Variables](./env_vars.md)

docs/caching_rendered_content.md

@@ -0,0 +1,12 @@
+# Caching and the `RenderedContent` model
+
+This model is mostly used as a database cache or backup for data that is retrieved from GitHub or from the S3 buckets.
+
+See [Static Content](./static_content.md) for more information about retrieving static content from S3.
+
+Usage:
+
+- Cache static content (like asciidoc content, library documentation, the help pages, anything that is rendered from S3). The `cache_key` field will be prefixed with `static_content_`.
+  - There is a Celery task to clear this database cache for all rows older than 7 days, which is set up to run daily.
+- Cache a copy of the library description (from the library asciidoc or other readme file). This enables us to load a library description even if the GitHub API goes down. The `cache_key` field will be prefixed with `library_description_`. Because these descriptions are primarily for past versions, they will not update, they will not be deleted from the database cache, and there is no need to retrieve them from GitHub fresh every time.
+- Store a copy of the release notes for each Boost version. Because the release notes are for past versions, they will not update, they will not be deleted from the database cache, and there is no need to retrieve them from GitHub fresh every time. The `cache_key` field will be prefixed with `release_notes_`.

docs/static_content.md

@@ -54,3 +54,9 @@ Take a look at this sample `{env}_static_config.json` file:
 - `/site/index.html`
 
 We first try to retrieve the static content using the exact S3 key specified in the site-to-S3 mapping. If we can't find the content using that key, we will try alternative S3 keys based on the `site_path` and `s3_path` properties in the `{env}_static_config.json` file.
+
+## Caching
+
+See [Caching and the `RenderedContent` model](./caching_rendered_content.md) for how Django-side caching is handled.
+
+Cacching is also handled via Fastly CDN.