Improve InvokeAI import patterns

[RyanJDick]

Problem

The InvokeAI import graph is a tangled web ripe with circular imports and import-order dependencies. We currently work around these issues with short-term hacks, but they are a hindrance to development. The good news is that these issues are generally easy to avoid by following some simple patterns.

Examples of workarounds for import issues:

• InvokeAI/invokeai/app/services/config/config_default.py

  Line 159 in bb6ff4c

  # note - would be better to read the log_format values from logging.py, but this creates circular dependencies issues

• InvokeAI/invokeai/backend/ip_adapter/ip_adapter.py

  Lines 140 to 141 in bb6ff4c

  	# workaround for circular import
  	from invokeai.backend.model_manager.load.model_util import calc_model_size_by_data

• InvokeAI/invokeai/backend/raw_model.py

  Lines 3 to 7 in bb6ff4c

  	The RawModel class is the base class of LoRAModelRaw and TextualInversionModelRaw,
  	and is used for type checking of calls to the model patcher. Its main purpose
  	is to avoid a circular import issues when lora.py tries to import BaseModelType
  	from invokeai.backend.model_manager.config, and the latter tries to import LoRAModelRaw
  	from lora.py.

• https://github.com/invoke-ai/invoke-training/blob/main/src/invoke_training/model_merge/scripts/merge_lora_into_model.py#L10-L14

Proposal

Here is a description of the direction that I think we should be moving to solve these problems (discussed offline with several members of the Invoke team):

1. Cross-directory imports should be one-directional. For example, files in invokeai/app/invocations are expected to import from invokeai.backend, but files in invokeai/backend should not import from invokeai.app.invocations.
2. Avoid re-exporting symbols from __init__.py files unnecessarily. This pattern makes sense for building clean public APIs, but most of our codebase is non-public (with the exception of invokeai.invocation_api). Also, re-exporting from __init__.py tends to lead to eager importing of modules before they are needed, which exacerbates circular import issues if the import tree is poorly structured, and could be contributing to the slow app launch times.
3. We have a bad habit of doing stuff on import. During import, we should only be defining classes/functions/constants - not executing code. This anti-pattern has led to several import-order dependencies.
4. Use absolute imports rather than relative imports. This is primarily a style preference, but PEP 8 recommends absolute imports, and in my experience they work better with Python LSP services (e.g. for auto-import and refactoring features). We currently have a mix of absolute and relative imports (mostly absolute) - we should standardize this. Also, if we enforce absolute imports with a linter, this makes refactoring easier. With absolute imports, if I move invokeai.app.service.some.module, then I can confidently search and replace all imports of this module. With relative imports, it is harder to find all references to the moved module.

Next Steps

This is intended to be a long-lived issue as we gradually work towards the proposed goal state over time. We won't try to solve all of these problem in a single pass.