Implement additional references to parent nodes for Type

[pkosiec]

Description

Implement Type feature: Additional references to parent nodes according to our documentation: https://capact.io/docs/feature/type-features/#additional-references-to-parent-nodes

• Handle the relation in Populator

• Support GraphQL filtering based on prefix
  - Find Types based on prefix of parent nodes (consider refactoring Cypher query to TypeScript)

• Update documentation to specify that this feature is implemented

Reason

With this feature, we are able to specify proper Implementation requirements (e.g. see the platform k8s/cloudfoundry example), as well as ability to define third-party Storage Backends in delegated storage.

[mszostok]

Enhancements:

• Add support to find Types based on prefix of parent nodes #620
  Add support for "Find Types based on prefix of parent nodes" - update Cypher to return related nodes (additionalRefs)

  • update README.md development section for hub-js

  • Populate additionalRefs to database, so it can be returned on GraphQL side:

    query GetCloudPlatform {
        types(filter: { pathPattern: "cap.type.platform.cloud-foundry" }) {
            prefix
            path
            revisions {
                revision
                spec {
    	            additionalRefs
                }
            }
        }
    }

    Output:

    {
        "data": {
            "types": [
    	        {
    		        "prefix": "cap.type.platform",
    		        "path": "cap.type.platform.cloud-foundry",
    		        "revisions": [
    			        {
    				        "revision": "0.1.0",
    				        "spec": {
    					        "additionalRefs": [
    						        "cap.core.type.platform"
    					        ]
    				        }
    			        }
    		        ]
    	        }
            ]
        }
    }

• Update populator to properly resolve requires section in Implementation #623
  Add support for "Requirements section in Implementation manifest" - in the requires section in populator

• Validate parent nodes in manifests #621
  Update validator to support new syntax

• Update docs about additionalRefs website#106

[mszostok]

Found issues

• I run into a problem with Node 17 and hub-js execution. investigate problem with not working node17 in hub-js
  Currently in Hub logs we can see:

  (node:18) [DEP0148] DeprecationWarning: Use of deprecated folder mapping "./public/" in the "exports" field module resolution of the package at /app/node_modules/extract-files/package.json.
  Update this package.json to use a subpath pattern like "./public/*".
  (Use `node --trace-deprecation ...` to show where the warning was created)

  when using Node 17 this warning becomes error:

  Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './public/extractFiles' is not defined by "exports" in node_modules/extract-files/package.json

  It is a problem with transitive extract-files dependency:

  $ npm ls extract-files
  hub-js@0.1.0 /Users/mszostok/workspace/go/src/github.com/capactio/capact/hub-js
  └─┬ neo4j-graphql-js@2.19.4
    └─┬ graphql-tools@7.0.5
      ├─┬ @graphql-tools/links@7.1.0
      │ └─┬ apollo-upload-client@14.1.3
      │   └── extract-files@9.0.0 deduped
      └─┬ @graphql-tools/url-loader@6.10.1
        └── extract-files@9.0.0

  We should use extract-files >= 10.0.0 which fixes the issue, but the neo4j-graphql-js is already deprecated, and I didn't find an easy way to fix that problem.

  As a fallback, I change my Node version to 16.

• Fix bug that for current main version (43c7400) where no entries are returned for empty filter:

  gotTypes, err := cli.ListTypeRefRevisionsJSONSchemas(ctx, gqlpublicapi.TypeFilter{
      // no path filter
  })

  Fixed in: Add support to find Types based on prefix of parent nodes #620

• Revisions are not supported as for Types query, we use only pathPattern without revision info. Additionally, additionalRefs - has only NodePath, see:

    additionalRefs:
    - cap.core.type.platform

  We can do that on client site, but it doesn't go well with our API, so I will log a dedicated issue for it.
  For now validator detects that in manifests: Validate parent nodes in manifests #621