refactor(workspaces): provider additions for collections under personal workspace

[jamesgeorge007]

Description

This PR ports the existing implementation for import/export, move/reorder, and search corresponding to collections under personal workspace to the provider-based new architecture. It also adds support for searching collections at any depth.

We're also moving to a new inert handle-based approach (proposed by @AndrewBastin). Previously, reactive handles were sent around everywhere with the provider methods expecting the same. This resulted in issues with the reactivity behavior mostly with the issued handle updates not getting reflected in the issued handles since the reference was coming up differently and the value getting automatically unwrapped at places. In the new approach, while obtaining a handle it's just a plain object and the underlying reactive value can be accessed at a later point in time.

const requestHandleResult = workspaceService.getRequestHandle(activeWorkspaceHandle, requestID)

if (E.isLeft(requestHandleResult)) {
  // Error handling
}

const requestHandleRef = requestHandleResult.right.get()

Personal workspaces have dynamic path-based IDs (0/0, 2/1/0, etc) based on the position (levels are separated by /, single digit represents root collections) of a resource (collection/request) in the tree. Previously to keep the association between requests open under tabs and the ones from the tree, every time the resultant IDs were computed manually after the action. Say, a request at a deeply nested collection is moved to a different location, each tab has information persisted about the ID path of the request being open from the tree and necessary updates are made to the above information based on the action computed from the source and destination IDs.
With the new handle-based system, since handles are reactive references to a resource, we keep a list of issued handles (creating/selecting a request,) and each tab keeps a request handle reference under tab.document.saveContext, and whenever an action requiring updates to the IDs happens, the corresponding handle is found from the compiled list of issued handles and the respective ID (collectionID, requestID) is updated accordingly and the updates are streamed to the tabs via the reactive behavior. The same approach is used for toggling the dirty state associated with requests when any parent level collection is deleted or if the request itself is deleted.

Closes HFE-437.

Changes

• Adds the following methods under the personal workspace provider corresponding to the abovementioned features.

  // Views
  getRESTSearchResultsView(
    workspaceHandle: HandleRef<Workspace>,
    searchQuery: Ref<string>
  ): Promise<E.Either<never, HandleRef<RESTSearchResultsView>>>
  getRESTCollectionJSONView(
    workspaceHandle: HandleRef<Workspace>
  ): Promise<E.Either<never, HandleRef<RESTCollectionJSONView>>>
  
  importRESTCollections(
    workspaceHandle: HandleRef<Workspace>,
    collections: HoppCollection[]
  ): Promise<E.Either<unknown, HandleRef<WorkspaceCollection>>>
  exportRESTCollections(
    workspaceHandle: HandleRef<Workspace>,
    collections: HoppCollection[]
  ): Promise<E.Either<unknown, void>>
  exportRESTCollection(
    collectionHandle: HandleRef<WorkspaceCollection>,
    collection: HoppCollection
  ): Promise<E.Either<unknown, void>>
  
  reorderRESTCollection(
    collectionHandle: HandleRef<WorkspaceCollection>,
    destinationCollectionID: string | null
  ): Promise<E.Either<unknown, void>>
  moveRESTCollection(
    collectionHandle: HandleRef<WorkspaceCollection>,
    destinationCollectionID: string | null
  ): Promise<E.Either<unknown, void>>
  reorderRESTRequest(
    requestHandle: HandleRef<WorkspaceRequest>,
    destinationCollectionID: string,
    destinationRequestID: string | null
  ): Promise<E.Either<unknown, void>>
  moveRESTRequest(
    requestHandle: HandleRef<WorkspaceRequest>,
    destinationCollectionID: string
  ): Promise<E.Either<unknown, void>>

• Migrate to the new inert handle-based approach.

• Move to handle based updates to keep the association between requests from the collection tree and the one's open under tabs.

• Additions to the NewCollectionsRest component accounting for the ported features mentioned above. The business logic associated with updates to the store for each action resides in the provider definition for each workspace invoked from the component level via the new workspace service implementation.

• Move the markup and associated logic wrt showing the active workspace and search from the parent level NewCollections component to `NewCollectionsRest.

• Port the collection/request move/reorder logic (markup, events, handlers, etc) into the NewCollectionsRestCollection and NewCollectionsRestRequest components.

• Introduce a new tree adapter to render the tree with search results. This was required since the existing adapter for rendering the default collection tree operates based on the supplied workspace handle. While, for search, is to be based on the initial data provided to be filtered based on.

• The getChildren method to be implemented by the tree adapter now takes an additional argument signifying the type of the incoming node (collection/request). This acts as a safeguard to prevent errors with operations specific to a collection node.

• Remove collectionID from information persisted under the REST tab saveContext since requestID accounts for it.

• initializeDownloadCollection helper under ~/packages/hoppscotch-common/src/helpers/import-export/export is given an agnosic name initializeDownloadFile since it gets consumed in different contexts. The definition is updated to point to the platform definition to ensure the underlying platform defines the behavior.

• New helper functions under ~/packages/hoppscotch-common/src/services/new-workspace/helpers.ts to abstract common logic consumed in the provider method definitions.

• Formalise a system for creating a persistable handle reference that can be loaded back again - Persist request handles at runtime, write only the unique IDs (provider, workspace & request IDs) required to restore the handle to localStorage. Load the request handle back via the IDs at runtime.

• Introduce writable handles to signify updates to other handle references when an action is performed. For instance, a request from the collection tree is deleted and at the same time the handle issued is updated thereby the request handle persisted under tab saveContext is aware of the update (handle type is set to invalid) and toggles the dirty state in this case.

Checks

• My pull request adheres to the code style of this project
• All the tests have passed

[AndrewBastin]

lgtm