build: begin linting imports

[kdmccormick]

Blockers

1. https://github.com/edx/edx-platform/pull/27875 : ensure every python source dir has an __init__.py
2. https://github.com/edx/edx-platform/pull/27874 : remove dependency of xmodule on cms
3. refactor: import common/lib/ modules from canonical locations #30533 : normalize capa and xmodule imports
4. refactor: move common/lib/capa/capa to xmodule/capa #30791
5. Need to write an ADR to accompany this

Description

This PR installs and configures import-linter. We start with a fairly light set of constraints; for example, we declare that lms_should_not_depend_on_cms, with a few existing exceptions. Over time, we could make these constraints stricter. The linter is run as a GitHub Action on PR builds and the master branch.

Rationale

In order to empower refactoring, restructuring, and extraction of edx-platform code, we would like to be able to analyze and make assertions about what code depends on what. One way to do this is by computing the digraph of Python import statements in our codebase, and failing PR builds if unwanted imports exist in the graph. This is exactly what the tool import-linter will allow us to do.

Example

LMS-specific code belongs in ./lms, and CMS-specific code belongs in ./cms. Since we want to decouple LMS and CMS, we don’t want code in one of these folders to import code in the other.

Using import-linter , we can fail any PR that adds a cms import to a module within lms. We can add exceptions for existing imports.

Supporting information

See BOM-2576 for context and details.

Testing instructions

Run make lint-imports locally within lms-shell and studio-shell. Make sure the check passes.

Add an illegal import (for example, from cms.djangoapps.contentstore import views within any lms module). Make sure the check fails, and make sure the output is comprehensible.

Deadline

None.

Other information

• Upon merging, we'll want to communicate this new check in the forums and Slack, so that developers now how to resolve any
  import-linter failures that they see on their PRs. We'll want to educate folks on the importance of these checks so that they don't get frustrated and/or just add their forbidden imports to the "ignore" list.
• I had a more ambitious version of this over here. I closed that and decided to stick with rules that don't have so many exceptions.

[kdmccormick]

Ugh, the pylint build just started failing with something wacky.

Once #30533 is through, I'll rebase, which'll hopefully resolve pylint.

[kdmccormick]

Huh, pylint's failing with something weird. I'll look into that soon.

[kdmccormick]

Closed in favor of #31062