chore: add standardized vscode devcontainer for development

[dsisco11]

Summary

This PR adds a standardized VSCode devcontainer setup for the repository.
It allows developers to checkout branches (or mount the repo from a local folder) into a sterile and isolated container that contains a standard configuration for all tools required for development.

Included is a debugger setup for both the frontend & backend, located under the usual "Run & Debug" menu.
Additionally, a few VSCode build actions have been included (Ctrl+Shift+B) for common actions such as:

• Run frontend tests
• Run backend tests
• Install frontend packages
• Install backend packages

Discord Thread

There is a discussion thread in the discord forum on this work.
https://discord.com/channels/1020123559063990373/1360184927538249809

Dependency Caching

The devcontainer is configured such that all current packaging systems for the project (UV & PNPM) have their package-store directory mounted as a global named volume "invokeai-dev-cache".
What this means is that packages are downloaded into this volume and then linked into any devcontainer instance that needs them.
A named volume is used here instead of a bind mount due to performance penalties incurred when docker has to transfer between its virtual file system and the host file system.

InvokeAI Data Persistance

In order to keep the devcontainer isolated & sterile, the InvokeAI app data & models are only persisted for a given container instance.
What this means is that if you have to rebuild the container or open a new container instance, then the previous app data such as the database & downloaded models will be deleted.
This isn't a bad thing, it's good to be able to work on multiple branches without risk of one envrionment impacting another.

Proposal: Model-Store

Admittedly, having to redownload AI models is frustrating.
This is why I propose we implement a relatively simple feature, a .model-store directory similar to the existing .download-cache directory.
This model-store would function just like the PNPM or UV package-store.
The proposed behavior is such that when Invoke goes to download a model, it will first check the model-store and if the desired model folder is found then it will be linked into the usual download destination.
This will allow us to configure the devcontainer to do the same thing it already does for the UV/PNPM stores and mount a named global volume to invokes model-store, allowing downloaded models to be shared across all container instances.
Thus, reinstalling models when you create a new container (after a rebuild or such) will complete instantly!

Custom Node Development

The devcontainer also facilitates very easy node development by allowing custom-node folders or git-repos to be placed within .devcontainer/mounts/custom-nodes.
Node packages within this path are automatically mounted into the devcontainer.
This means the devcontainer can be used to both launch the development version of InvokeAI and develop custom nodes.
Source files for custom nodes within the devcontainer gain the benefit of being fully compatible with all dev tools such as Pylance and the Python debugger.

EDIT
Hot-Reloading for custom nodes now works!

Differences

There are a few things done differently in the devcontainer when compared to the traditional setup for InvokeAI.

Project Install

The project is installed using only the uv sync command, purposely excluding uv pip install.
This is because uv sync already installs the project in editable by default.

Removing Setuptools

Using setuptools as the build backend was causing excessive build times within the container (upward of 50 minutes).
This is possibly related to bugs such as this one.
The project has been migrated to using Hatchling, resulting in build times of around 2 minutes.

UV Index

Traditionally, the correct packages to be installed for a given compute device (CPU/CUDA/ROCM) have been determined by setting a special envar UV_INDEX during container builds.
The problem is that there is logic required to determine the value for this envar, and the envar has to be set at multiple different stages.
Additionally, specifying an override-index like this would cause uv lock to produce a different lockfile for different developers (based on the compute-device they use, which determines their UV_INDEX value).

To fix these issues, I have created a package resolution setup in the UV section of pyproject.toml.
This setup uses a few custom 'extras' values along with the system/platform identifiers to determine which index to pull from.
Now, rather than manually setting an envar, one of the following extras can be specified to indicate which compute-device-type is being used.

• --extra using-cuda
• --extra using-rocm
• --extra using-cpu

If none of these extras are specified then the system will just default to CPU.
For MacOS (system_platform=='darwin') no special index is used and the default index is chosen.

This completely eliminates the need to manually specify a UV index and now the switching logic lives inside the pyproject config!

[hipsterusername]

This is awesome. Thanks for contributing - we will take a look at it this week.

[psychedelicious]

Hell yeah, thank you for working on this! I'll take some time to test next week.

[psychedelicious]

Looking good! Left a few comments.