Make key quality of life updates to automated archiving

[e-belfer]

The following challenges were observed in the September archive #412, and would speed the pace of monthly archiving:

Tasks

Preview Give feedback

1. adding a flag to delete drafts with no changes, and turning it on for the automated archive run. This will remove the step of manually deleting draft archives, which is done anyways to avoid having draft PRs cluttering Zenodo. This should not be the setting by default for local runs, but we can change the setting for the Github action. Restore delete_deposition method, update AEO doi, sort FERC taxonomies #419
2. Handle FERC taxonomy keys: sort the keys, to avoid changes in sorting creating new partition changes Restore delete_deposition method, update AEO doi, sort FERC taxonomies #419
3. Investigate partition "changes" when updating FERC archives #399
   ferc1 ferc2 ferc6 ferc60 ferc714 +5
   
4. Handle FERC taxonomy keys: ensure that null keys (e.g. for FERC 1996) don't get marked as updated files
5. Add the size of changes to the slackbot report to enable more rapid assessment of changes #473
   +0
6. Add better zip comparison functionality #471
   +0

[zschira]

I've done some further research into the erroneous FERC XBRL archive updates and found the following:

1. he hashes of the zipfiles do differ
2. The contents of the zipfiles are, however, identical and there are no longer partition changes, meaning Fix erroneous FERC XBRL updates #433 did fix the partition change error and the changes to the rssfeed file
3. The sizes of the zipfiles are identical
4. The timestamps of the files within the zips are identical

I'm still not really sure how/why the zips are differing. I tried creating a test to create 2 archives and check the hashes, but I'm unable to reproduce the error.

I'm going to try modifying the XBRL archivers to use our existing add_to_archive_stable_hash method and create two new archive versions for comparison. It does feel like directly comparing hashes of zipfiles is probably a bit fragile and a more in depth comparison might be better, but if add_to_archive_stable_hash solves the problem then it's probably good enough for now.

[jdangerx]

Pulled out remaining pieces. closing