standardize branch options for DevDB and FacDB

[damonmcc]

resolves #265

changes

• improve method of giving options for data to review for Dev DB QA
• use the same approach for FacDB
• improved lambda function formatting of directory URLs by not having a backslash at the end, making the use of the returned string more readable

notes

• maintaining blacklists and/or whitelists to manually filter Digital Ocean folders and github branches is not ideal
• get_active_s3_folders approach for getting list of options for data to review :
  • get a list of all branches in the repo
  • get a list of all output folders in Digital Ocean
  • use the intersections of those two lists
  • put the default branch first in the dropdown selection
• thinking behind the above approach:
  • data is in Digital Ocean in folders named after the github branch which generated it
  • if a github branch doesn't exist anymore, the data it generated shouldn't be considered "active" and in need of review/useful in the QAQC app
  • otherwise, the dropdown selection would be as long as every branch we've ever used to run a build (for production, test, dev, ...)
• I manually archived many Digital Ocean folder into a folder called ARCHIVED

screenshots

[damonmcc]

hey @fvankrieken, I wrote lots of notes in the PR description since I know you wanted to really think about how we should do the branch/folder list. this is an approach I thought might be nice but could definitely see how it might be overly restrictive, especially for reviewing old data

[fvankrieken]

Haven't gone over the code yet, but from the description it doesn't seem like it'd be restrictive - for old branches, in our workflow those changes generally should make it into main and then ideally trigger a build, we really should only need to use non-main branches for comparison when we're actively working on those branches. Main case I can see is if someone promptly deletes a branch on merge and then for some reason we still want to compare that to main, but in that case I would say maybe we just shouldn't be deleting branches until features back on main have been tested properly (i.e. build and compare to feature branch, which should be identical)

[fvankrieken]

Or I guess thinking about a case like EDDE this past time - numerous merges to main from numerous feature branches, which I didn't really compare between but could see the use for as sort of forensics, if something was missing see if it was introduced at intermediate point. But regardless, think that can just be handled by not deleting feature branches until data output is where we want it to be

[fvankrieken]

Lgtm, I personally would like to go this route and then we can iterate if we have issues with it