Consider updating workflow triggers that reference both 'push' and 'pull_request'

[jgravois]

From the looks of #1180, we enabled 'pull_request' as a tests-pytest.yml trigger in order to support contributions from forked repositories and we've tolerated some duplication ever since.

now that pull requests from non-contributors are disabled, since we don't have that enabled anymore, it would be a nice quality of life improvement to update our triggers and avoid running duplicate github actions when pull requests are updated.

Acceptance Criteria

• the workflows below only run once when a pull request is opened and when subsequent commits are pushed to the branch.
• the workflows below continue to run on push to main

• tests-pytest.yml
• codeql.yml
• check-dynamic-version.yml
• check-migrations-and-messages.yml

Additional context

nasa/cFS#169

[Scotchester]

I think I'd flip it around? I'm not sure we want it to run on any branch push before a PR is open. How about running on PRs, but then only run on a simple push if it's to main (to catch a regression if a PR that is not current gets merged and causes a test failure).

I think (but need to verify) that a check triggered by pull_request checks against the result if that were merged into the base branch, which a check triggered by push just checks against that commit?

(There are several other workflows that run on both events that could also be just one or the other.)

[Scotchester]

I think (but need to verify) that a check triggered by pull_request checks against the result if that were merged into the base branch, which a check triggered by push just checks against that commit?

Confirmed: https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows#how-the-merge-branch-affects-your-workflow

[jgravois]

a check triggered by pull_request checks against the result if that were merged into the base branch

TIL!