brainstorm/proof of concept: gzip releases

[brian-smith-tcril]

in order to implement the gzip release strategy proposed in OEP-58, the question of "when do we trigger a build/release" will need to be answered.

at a high level, we want to trigger a release when we get new translations from transifex

breaking that down a little it gets a bit more complicated. when looking through the commits, it's notable that there are 2 from the transifex bot within a minute of each other

this makes me think that the transifex gh app will make a bunch of commits in a row every time updated translations are approved, so using commits from that bot as a trigger would lead to a bunch of releases all in a row

another aspect to think about is versioning, an easy way to handle releases is to trigger a build/release when a new tag is pushed, so doing that could work quite well, it just raises the question of when to push tags (and what tag to push in the case of updated translations for named releases)

one implementation that comes to mind is to just run a cron job like we do for the source files, check for any updated translated strings (or check for new commits by the transifex bot), and push a tag if we find those

[brian-smith-tcril]

after more discussion, gzip releases seem to add more complexity than some of the other proposed options. continued discussion on how to pull translations into MFEs during the build/deployment process here: openedx/openedx-atlas#4