feat(nodes/ui): refactor field types, workflows

[psychedelicious]

What type of PR is this? (check all applicable)

• Refactor
• Feature
• Bug Fix
• Optimization
• Documentation Update
• Community Node Submission

Have you discussed this change with the InvokeAI team?

• Yes
• No, because:

Have you updated all relevant documentation?

• Yes - at least, I have added many comments to what was previously unintelligible code
• No

Description

This PR is a substantial refactor of the frontend workflows logic.

There are some minimal changes to python code to support the frontend changes.

Python Changes

• Deprecate most UIType enum members, which are no longer needed. If a
  deprecated type is used, a warning will be logged and the type ignored.
• Deprecate the default_factory arg to InputField() and OutputField(). If
  this arg is used, the callback will be called during invocation registration,
  and set as the default value. A warning will be logged.
  • This doesn't change anything in the core application - in the cases where a
    callback could actually do something (like a random seed), we actually
    always provided a valid value directly, so the callbacks were never actually
    called during graph execution.
  • In the future, we can explore restoring this functionality.
• Organization/renaming of helper classes (e.g. _InputField ->
  InputJSONSchemaExtra)
• Handle edge cases for field validation during invocation registration
• Surface the module name of custom nodes to the frontend as "node_pack"
• Improved/added comments throughout

Changes outside baseinvocation.py are minor and support these changes.

Frontend Changes

The main frontend change is a refactor of fields, workflows and their types.

This involved renaming and shuffling many files and so there are a ton of small
changes throughout the code with new names or import paths.

Fields

The biggest changes are to fields, particularly field types.

Field Types

Previously, field types were strings. For example, integers would be
"integer", "IntegerCollection" or "IntegerPolymorphic".

Adding a new field type was a major pain, and there was a lot of fiddly logic
related to edge validation.

Field types are now structured. Here's integer:

type T = {
  name: 'IntegerField'; // literal
  isCollection: boolean;
  isPolymorphic: boolean;
};

Stateful and Stateless Field Types

Fields are now conceptually categorized as stateful or stateless.

Stateful fields are things like integers, strings or images. They have state
(value) in the frontend, and UI components allowing users to change their value.

Stateless fields are things like UNetField or ControlField. The user cannot
directly change these fields - they are created and consumed only in python - so
they have no UI component.

The signature of a stateless field type is a wider version of a stateful field:

type T = {
  name: string;
  isCollection: boolean;
  isPolymorphic: boolean;
};

The handling of fields is now generalized such that node authors may freely
create pydantic models for their fields. Many "official" field types are
stateless, and all "custom" field types in community nodes are stateless.

Connection validation still works as it did previously.

zod Schemas and Types

All workflow-related schemas and types have been rewritten, see files in
invokeai/frontend/web/src/features/nodes/types/.

Almost everything is now a zod schema with inferred TS types (previously there
was a lot of pure TS). The OpenAPI schema types are still pure TS.

The naming conventions for these things have been revised and made consistent.

There are many small changes in components and hooks resulting from newly named
schemas, types and type-guards.

Other Changes

• Migration logic for workflows implemented (see
  invokeai/frontend/web/src/features/nodes/util/workflow/migrations.ts)
  • We are now on workflow schema version 2.0.0. v1.0.0's schemas are retained
    in invokeai/frontend/web/src/features/nodes/types/v1/ and used during
    migration.
• Community nodes' node packs are displayed in the info icon tooltip for a node
• Improved workflow loading (includes migration, validation, and improved user
  feedback)
• Improved node updating logic & UI/UX
• If a node in loaded workflow is missing from the user's install, the node type
  and node pack name will be displayed
• Linear UI parameter schemas are cleaned up and deduped (was duplication w/
  some field schemas)
• OpenAPI schema parsing logic simplified, edge cases handled
• Added many strings to translation system
• Updated README.md
• Added WORKFLOWS_DESIGN_IMPLEMENTATION.md, a high-level review of workflows and
  their implementation on frontend
• A number of minor bug fixes / edge cases
• Improved/added comments throughout
• Fixed polymorphic fields not able to be added to workflow linear view

Related Tickets & Documents

• Related Issue Add image tiling nodes to enable Tiled Upscaling #5142
• Supersedes and Closes feat(ui): add support for custom field types #5113
• Closes [bug]: unable to add a cfg field to the linear ui from the workflow editor #4720

QA Instructions, Screenshots, Recordings

Sorry for the size of this. I don't think I could split up the frontend changes into separate PRs without breaking the app - I rewrote a substantial portion of workflow-related logic across the frontend, and a partial implementation would leave it nonfunctional.

The changes are scoped to the workflow editor. Workflows that work on 3.4.0post2 should work in this PR.

You should be able to add custom fields. I made a small node pack with custom fields to test.

Everything in the workflow editor should work just like it did before.

[psychedelicious]

I have been working from my fork, which prevents me from stacking another PR on this one.

I've remade this PR in #5175, which merges from origin instead of my fork. Closing in favor of #5175.