feat: diagram edit handling COMPASS-9312

[paula-stacho]

Description

• added zod definitions to the storage
• types are derived from the zod definitions
• zod also used for edit validation
• added placeholders for add/remove relationship

TODO:

• validation
• tests

Checklist

• New tests and/or benchmarks are included
• Documentation is changed or added
• If this change updates the UI, screenshots/videos are added and a design review is requested
• I have signed the MongoDB Contributor License Agreement (https://www.mongodb.com/legal/contributor-agreement)

Motivation and Context

• Bugfix
• New feature
• Dependency update
• Misc

Open Questions

Dependents

Types of changes

• Backport Needed
• Patch (non-breaking change which fixes an issue)
• Minor (non-breaking change which adds functionality)
• Major (fix or feature that would cause existing functionality to change)

[paula-stacho]

How I ran into this: I felt like it's unnecessarily complex to go deep with the zod schemas and basically re-define MongoDBJsonSchema.
But having it typed in TS does make sense. So it has to be cast somehow. I suppose I could go into more detail here, but I figured this would be enough for the load. Let me know if you have a better idea

[gribnoysup]

I understand that we probably don't want a full blown validation of MongoDBJSONSchema type implemented here, but I think we might want to consider using z.custom here, provide the MongoDBJSONSchema as a generic argument and maybe adding some very basic validation for the type matching. The purpose of these z.<type> helpers is not only to get the type definition after all, but to actually build a validator that makes sure that data, in our case, you're loading from disk (and at some point user will be passing to the app) is matching the shape that we need for this to function.

[paula-stacho]

oh thank you! this makes it so much smoother 🫶

[mabaasit]

the test failure seems to be legit