Develop binding/staging of "releases" of dandi-infrastructure with related other components (e.g. dandi-archive)

[yarikoptic]

Came up in discussion with @dandi/ember is that there is a difficulty and unclear sequence of how to apply upgrades in dandi-infrastructure and dandi-archive releases. Similarly we had recent issue dandi/dandi-archive#2533 due to out-of-desired-order of dandi-archive release and application of dandi-infrastructure changes (#245).

I wondered what could be the way to implement that.

[NEStock]

Example of problems that can come up in a fork: aplbrain#42

Some context:

• We were aiming to "sync" our forks at a monthly cadence, pulling in all the changes from dandi-archive and dandi-infrastructure at one time
  • In dandi-infrastructure, sometimes statements get added for a time and then later removed from the code (i.e. a moved statement, signally to Terraform that some resource has changed its address). This can cause issues for forks who are not syncing every commit incrementally, because by the time we update our code, some moved statements may have been added and then removed from the code, meaning that we actually wouldn't see (or know about) them at all.

Some thoughts:

• linking the versions/commits of dandi-archive and dandi-infrastructure that "go together"
• adding a changelog to dandi-infrastructure, similar to dandi-archive
• versioning dandi-infrastructure in such a way to highlight if there are "incremental" changes that need to be applied in stages (vs. all at once)
  • example: when a moved statement is added or removed ?
• notes on order of operations between dandi-archive and dandi-infrastructure (if one needs to be applied before the othe)