Add constructor functions for run-time types

[dsainati1]

Closes #1137

Description

Users have requested the ability to produce run-time types from their identifiers. #1137 suggested using the string representation of the type, but this is not robust and has potential security concerns. Instead, this PR adds an API to allow users to dynamically construct run-time types.

fun CompositeType(typeID: String): Type?
fun InterfaceType(typeID: String): Type?
fun OptionalType(type: Type): Type
fun VariableSizedArrayType(type: Type): Type
fun ConstantSizedArrayType(type: Type, size : Int): Type
fun FunctionType(params : [Type], return : Type) : Type
fun DictionaryType(key k: Type, value v: Type): Type?
fun RestrictedType(type : String, restrictions : [String]) : Type?
fun CapabilityType(type : Type) : Type?
fun ReferenceType(authorized : bool, type : Type) : Type

In order to re-use the static typechecking we do to ensure the integrity of restricted types, this also refactors to decouple the functionality of checking the correctness of a restricted type from reporting any type errors associated with that type. This way the interpreter can re-use the logic to return nil in scenarios where the checker would have rejected a restricted type.

---

• Targeted PR against master branch
• Linked to Github issue with discussion and accepted design OR link to spec that describes this work
• Code follows the standards mentioned here
• Updated relevant documentation
• Re-reviewed Files changed in the Github PR explorer
• Added appropriate labels

[codecov-commenter]

Codecov Report

Merging #1195 (d14cb20) into master (b947b91) will increase coverage by 0.12%.
The diff coverage is 89.34%.

@@            Coverage Diff             @@
##           master    #1195      +/-   ##
==========================================
+ Coverage   77.03%   77.15%   +0.12%     
==========================================
  Files         273      273              
  Lines       33962    34132     +170     
==========================================
+ Hits        26163    26335     +172     
+ Misses       6732     6728       -4     
- Partials     1067     1069       +2     

Flag	Coverage Δ
unittests	77.15% <89.34%> (+0.12%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
runtime/interpreter/errors.go	23.38% <0.00%> (-0.78%)	⬇️
runtime/sema/checker.go	89.26% <82.35%> (+0.37%)	⬆️
runtime/interpreter/interpreter.go	88.92% <92.61%> (+0.93%)	⬆️
runtime/interpreter/value.go	82.16% <100.00%> (+0.01%)	⬆️
runtime/sema/type.go	87.58% <100.00%> (+0.04%)	⬆️
runtime/interpreter/statictype.go	68.89% <0.00%> (+1.91%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b947b91...d14cb20. Read the comment docs.

[bluesign]

This feels little bloated to me to be honest. Do we really need this much options?

What are the security and robustness concerns for Type(String) ?

[dsainati1]

This feels little bloated to me to be honest. Do we really need this much options?

What are the security and robustness concerns for Type(String) ?

This isn't any more bloated than directly parsing the string; if anything it provides a cleaner API. Consider an example where you have a struct ID called typeID saved in storage, and you want to create a runtime type of an array of that struct. If you must directly parse the string, you would need to do something like Type("[".concat(typeID).concat("]")), which is significantly less readable and more brittle than the equivalent using this API: VariableSizedArrayType(CompositeType(typeID)!). This places less of the burden for properly constructing the type onto the developer; it is much easier to make a mistake when concatenating potentially long strings together than when interacting with an API. The implementation is also more brittle as well; we would need a new parser to parse the input string.

As for security, whenever we parse strings directly into runtime values there is always the concern of users providing malicious input; one can imagine a scenario in which a developer might try to parse user input into a runtime type and make decisions based on that; using a limited API lowers the risk associated with this kind of thing.

[bluesign]

For me this is a bit strange example because honestly I can't imagine any practical use case.

[dsainati1]

The issue linked in the summary contains a link to a discussion about NFT metadata. Users would like to be able to store type identifiers in the metadata of their NFTs, and construct types at runtime from those identifiers.

[turbolent]

Great work! 👏

This is almost done, just a few small things 👍

[SupunS]

Looks great! 👏

[turbolent]

Looks good! Just one last request to rename the error, but should be good to merge after that. Nice work!