Use new subject / schema loader methods / routes when populating the topic and schema views

[jlrobins]

Summary of Changes

• Migrate the creation of the TreeItems representing subject groups and schemas within the topic and schema views to be based off of ResourceLoader.getSubjects() and .getSchemaSubjectGroup() instead of ResourceLoader.getSchemas(). This removes majority of calls to get LIST /schemas route as spelled by loader.getSchemas...().
• While doing so, create new model object Subject representing a subject loaded from a particular schema registry. Adjust ResourceLoader.getSubjects() to return array of those instead of bare strings, because of need to know the source registry's particulars when invoking actions like 'evolve schema', 'view latest schema,' etc from the views.
• The original intent of this branch was to just update all of the route calls from the schema registry view, but upon realizing that the schema-manipulating commands are invoked from both the schema registry view as well as the topics view, I had to cover both.

Schemas View

• Toplevel items are Subject instances. Because those subject instances are born from just the subject strings, we lose knowing what schema type and count of versions within the corresponding schema subject group, so the schema view rows no longer show those facts.
• When a subject is expanded, and getChildren() is called, we then fetch all of the schema bindings for that subject using ResourceLoader..getSchemaSubjectGroup() returning a Schema[].

Topics View

• Toplevel items remain KafkaTopic. They are built with knowledge of the subjects within the schema registry, and will be expandable if one or more subject correlates by name.
• If expandable, its children will be ContainerTreeItem<Schema> as before, populated through getting all of the subjects, then filtering by the topic, then fetching the schema group for the remaining subjects. Because this process requires preemptively fetching all of the schemas for these single-topic-matching-subjects (usually only one or two subjects), we can paint the subjects also with knowledge of the schema type and count of versions.

Commands

• Alas, now commands like 'view latest schema,' 'evolve latest schema,' and 'Upload schema to registry for subject' can now be invoked on either a ContainerTreeItem<Schema> (from topics view) or a Subject, so new type union for the argument type for those commands is needed, Subjectish, representing something from which (subject string, schema registry id, connection id, environment id) can be extracted. New utility functions determineSubject and determineLatestSchema in src/commands.schemaUtils.ts are used to navigate from the Schemaish argument to the underlying desired object.

Any additional details or context that should be provided?

• Closes Wean schema view controller off of ResourceLoader.getSchemasForRegistry()  #952
• Closes Create SchemaSubject model and stop using ContainerTreeItem<Schema> #1021, although I still use ContainerTreeItem<Schema> within the topics view hierarchy. New class is src/models/schemas.ts's Subject, and can be obtained from a Schema instance via method subjectObject().
• Highlights need for ResourceLoader.getSubjects() to preemptively cache results per schema-registry, regardless of the ResourceLoader implementation. New ticket All implementations of ResourceLoader.getSubjects() need to cache #1051 written.

Pull request checklist

Please check if your PR fulfills the following (if applicable):

Tests

• Added new
• Updated existing
• Deleted existing

Other

• All new disposables (event listeners, views, channels, etc.) collected as for eventual cleanup?

• Does anything in this PR need to be mentioned in the user-facing CHANGELOG or README?
• Have you validated this change locally by packaging and installing the extension .vsix file?

  gulp clicktest

From Copilot's perspective:

This pull request introduces significant changes to the schema handling functionality, including refactoring functions to use a new SubjectishArgument type, adding utility functions to determine schema subjects, and updating tests to reflect these changes.

Key changes include:

Refactoring and Utility Functions:

• src/commands/schemaUpload.ts: Refactored uploadSchemaForSubjectFromfile and uploadSchemaFromFile functions to use SubjectishArgument and introduced determineSubject for subject extraction. [1] [2] [3] [4] [5]
• src/commands/schemaUtils.ts: Added new utility functions determineSubject and determineLatestSchema to handle different types of subject arguments.

Testing:

• src/commands/schemaUtils.test.ts: Added tests for the new utility functions determineSubject and determineLatestSchema.
• src/loaders/loaderUtils.test.ts: Updated tests to validate the correct order of fetched schema versions and subject strings. [1] [2]

Schema Handling:

• src/loaders/loaderUtils.ts: Modified the fetchSubjects function to return Subject objects instead of strings and updated fetchSchemaSubjectGroup to return schemas sorted by version. [1] [2] [3]
• src/loaders/resourceLoader.ts: Updated getTopicsForCluster and getSubjects to handle Subject objects. [1] [2] [3] [4]

Command Updates:

• src/commands/schemas.ts: Updated commands to use the new determineLatestSchema utility function for handling schema subjects. [1] [2] [3]

These changes collectively improve the flexibility and robustness of schema handling by introducing a more versatile argument type and ensuring consistency across related functions and tests.

[Copilot]

Copilot reviewed 5 out of 17 changed files in this pull request and generated 1 comment.

Files not reviewed (12)

• src/models/schema.test.ts: Evaluated as low risk
• src/loaders/resourceLoader.test.ts: Evaluated as low risk
• src/quickpicks/schemas.ts: Evaluated as low risk
• src/commands/schemas.ts: Evaluated as low risk
• src/commands/schemaUpload.ts: Evaluated as low risk
• src/viewProviders/schemas.test.ts: Evaluated as low risk
• src/loaders/loaderUtils.test.ts: Evaluated as low risk
• tests/unit/testUtils.ts: Evaluated as low risk
• src/loaders/resourceLoader.ts: Evaluated as low risk
• src/loaders/loaderUtils.ts: Evaluated as low risk
• tests/unit/testResources/schema.ts: Evaluated as low risk
• src/viewProviders/topics.ts: Evaluated as low risk

[shouples]

Suggested change

	* Wrapper around {@linkcode uploadSchemaFromFile}, triggered from an inline actions:
	* Wrapper around {@linkcode uploadSchemaFromFile}, triggered from inline actions:

[shouples]

Is this supposed to be a Subject and a Schema? Or a Subject and a SubjectTreeItem?

[shouples]

I've read through more, and I think I see where I was confused -- this basically splits it into "was this called from the Topics view (ContainerTreeItem) or Schemas view (Subject)", right?

[shouples]

Is there any reason we can't use schemas: Schema[] = [] and an optional type for when we handle the preloading so we don't have to use ContainerTreeItem<Schema> in the Topics view? I feel like the Subjectish split between Subject and ContainerTreeItem<Schema> is making this more complicated since we use them in the same way in each view (but the Topics view has the KafkaTopic parent items). 🤔

[shouples]

Still need these three debug logs?