Disable using type information from IID in type inference

[flyingsilverfin]

Usage and product changes

We decide to ignore IID information when performing type inference. This comes from the idea that IIDs are data, and the user may be trying to check whether the data conforms to a specific part of the schema. Previously, this will cause a query to throw an error due to type checking incompatibility, which made common expressions in fetch subqueries very difficult

Fetching stocks for books that are able to have stock (some subtypes of books do not have stock, such as 'ebook'):

match
$x isa book;
fetch:
stock: { 
  match $x isa! $t; $t owns stock;
  fetch $x: stock;
};

Which will retrieve stock for books, if the polymorphically selected book instance is able to own 'stock' attributes.

This expression now returns an empty list for instances of books that cannot own stocks instead of returning an error.

Implementation

• We remove the use of type information extracted from query IIDs from impacting type inference

[vaticle-bot]

PR Review Checklist

Do not edit the content of this comment. The PR reviewer should simply update this comment by ticking each review item below, as they get completed.

---

Trivial Change

• [ ] This change is trivial and does not require a code or architecture review.

Code

• [ ] Packages, classes, and methods have a single domain of responsibility.
• [ ] Packages, classes, and methods are grouped into cohesive and consistent domain model.
• [ ] The code is canonical and the minimum required to achieve the goal.
• [ ] Modules, libraries, and APIs are easy to use, robust (foolproof and not errorprone), and tested.
• [ ] Logic and naming has clear narrative that communicates the accurate intent and responsibility of each module (e.g. method, class, etc.).
• [ ] The code is algorithmically efficient and scalable for the whole application.

Architecture

• [ ] Any required refactoring is completed, and the architecture does not introduce technical debt incidentally.
• [ ] Any required build and release automations are updated and/or implemented.
• [ ] Any new components follows a consistent style with respect to the pre-existing codebase.
• [ ] The architecture intuitively reflects the application domain, and is easy to understand.
• [ ] The architecture has a well-defined hierarchy of encapsulated components.
• [ ] The architecture is extensible and scalable.