[Issue #2371] Rename agency to agency_code in API + DB

[chouinar]

Summary

Fixes #2371

Time to review: 10 mins

Changes proposed

High-level - renamed agency in the opportunity models to agency_code - both at the API and DB layer

Remove agency name and agency code from the opportunity summary response object (should not be used - the opportunity values are more accurate)

A lot of fixes for tests that were checking for the old name

Deleted an import-csv script that wasn't needed anymore (and would've needed fixes)

Context for reviewers

agency is way too generic of a name, and agency_code makes more sense.

Agency info is also split across an opportunity and summary. Some of this was duplicated (code and name) and we want to avoid confusion by having these values duplicated.

Additional information

Did a quick pass on the existing search UI, don't see anything having broken yet. Query box, sorting, and filters all work, as well as the agency itself being displayed in search. I also switched the frontend to use v1 and didn't see any issues

[doug-s-nava]

Made a couple of notes on the ticket but I agree that everything seems to check out here. We'll have some minor updates to make on the frontend before deprecating the existing opportunity.agency but we can coordinate that later.

[emilycnava]

lgtm! (checked locally and didn't see any noticeable errors on FE)

[emilycnava]

@doug-s-nava I wonder I know you mentioned visual diff checkers in a PR the other day, I assume something like that would have helped here as well? How complex are those tools to implement?

[doug-s-nava]

Getting an error on make migrate-db-down: psycopg.errors.UndefinedColumn) column "agency_code" does not exist

[doug-s-nava]

@emilycnava 🤔 I feel like a visual differ could help in situations like this to uncover bugs, but I think e2e tests would be even more effective with that since they take user interaction into account. The way we're using e2e tests at the moment, we wouldn't have caught something like a text change here, though. In any case, for a testing scenario to catch an issue in a change like this we'd have to carefully choose the examples we're using. For example, to catch a bug with how agency data is displayed we'd have to make sure to be running our tests against an opportunity that is affected by the change - an opportunity with no agency data or, perhaps, agency data that matches between the opportunity and the summary, may not show us that anything is wrong. Interesting to think about for the future.

Visual differs are not super hard to set up. However:

• they cost money
• they can be finicky similar to how e2e test are in terms of false negatives, and as a result there is some overhead in terms of maintenance

[mdragon]

Looks good as long as FE likes it.