fix: Make image table's project, registry_id column nullable

[jopemachine]

Follow-up of #1917.

• Refactoring the image rescan command

  • Although the existing image rescan command works well, unfortunately, the code does not align with the original design intent. The existing rescan_images code is designed to work with multiple container registries, but because it is not project-aware, it only operates on the last record. This issue is addressed by iterating over all container registries in rescan_single_registry, but this is not the correct approach.
  • This code has been refactored to return the project iteration loop back to rescan_images.
  • Unfortunately, running multiple rescan_single_registry tasks concurrently has been found to trigger an abort. Therefore, I modified it to execute each iteration sequentially. While this results in a slight performance decrease, we can consider improving it to support parallel processing in the future.

• More flexible support for local-type container registries

  • Previously, even local-type container registries were constrained by the project value and the name of a non-existent virtual container registry. In this PR, all unnecessary restrictions have been removed, allowing local images to be scanned as they are.

• Make image table's project column nullable

  • If the "project" column is null, the string after the registry will be treated as the image name, following the existing logic.

• Make container registry table's project column nullable

  • This is primarily intended to provide more flexible support for local-type container registries, but it may also be useful for other use cases.

• Modified the upgrade() to automatically generate the corresponding container registry row instead of raising an error when no container registry exists for the image canonical name.

Thoughts

• Local-type container registry records currently do not contain meaningful information. Additionally, having more than one local container registry type would be awkward.

• Whether an image is local can be determined by checking if the container registry pointed to by image.registry_id is of the Local type, making the is_local column redundant.

Container registry row auto-generation example

🕙 18:58:36 ❯ ./py -m alembic upgrade +1
INFO  [alembic.runtime.migration] Context impl PostgresqlImpl.
INFO  [alembic.runtime.migration] Will assume transactional DDL.
INFO  [alembic.runtime.migration] Running upgrade 20218a73401b -> 1d42c726d8a3, Migrate container registry config storage from `Etcd` to `PostgreSQL`
INFO  [alembic.runtime.migration] Following container registry row auto-generated: "cr.backend.ai" with the project "multiarch".
INFO  [alembic.runtime.migration] If credential required for the auto-generated container registry rows, you should fill their credential columns manually.

Checklist: (if applicable)

• Milestone metadata specifying the target backport version

[achimnol]

Still it fails:

  File "/home/joongi/bai-edge/src/ai/backend/manager/models/alembic/versions/1d42c726d8a3_migrate_container_registries_from_etcd_to_psql.py", line 457, in upgrade
    insert_registry_id_to_images_with_black_registry_id()
  File "/home/joongi/bai-edge/src/ai/backend/manager/models/alembic/versions/1d42c726d8a3_migrate_container_registries_from_etcd_to_psql.py", line 381, in insert_registry_id_to_images_with_black_registry_id
    registry_info = dict(registry_info)
                    ^^^^^^^^^^^^^^^^^^^
TypeError: 'NoneType' object is not iterable

[jopemachine]

The current PR has become larger than initially intended, making it difficult to review. So, I will close this PR and recreate it as a PR stack in Graphite.

See #2978