refactor(app-gen): cache locking

[djabarovgeorge]

What changed? Why was the change needed?

This pull request is a work in progress and shouldn't be reviewed yet. It's the first step in a refactoring process, and the next stage will focus on reusing the applyLock method.

I'm also questioning where the locking logic belongs. While I like the cleanness of this solution, I'm unsure if the cache layer is the ideal place for it. Perhaps it should reside within a separate use case. I'd appreciate your thoughts on this matter.

Screenshots

Expand for optional sections

Related enterprise PR

EE

Special notes for your reviewer

[netlify]

❌ Deploy Preview for dev-web-novu failed. Why did it fail? →

Name	Link
🔨 Latest commit	dfadfe9
🔍 Latest deploy log	https://app.netlify.com/sites/dev-web-novu/deploys/665477d3e1e37b000826c126

[netlify]

❌ Deploy Preview for novu-design failed. Why did it fail? →

Name	Link
🔨 Latest commit	dfadfe9
🔍 Latest deploy log	https://app.netlify.com/sites/novu-design/deploys/665477d3344fb300081e3d31

[github-actions]

Hey there and thank you for opening this pull request! 👋

We require pull request titles to follow the Conventional Commits specification and it looks like your proposed title needs to be adjusted.

Your PR title is: refactor(app-gen): cache locking
It should be something like: feat(scope): Add fancy new feature

Details:

Unknown scope "app-gen" found in pull request title "refactor(app-gen): cache locking". Scope must match one of: root, api, inbound-mail, web, webhook, widget, worker, ws, ee-auth, ee-billing, ee-billing-web, ee-echo-api, ee-echo-web, ee-echo-worker, ee-dal, ee-shared-services, ee-translation, ee-translation-web, application-generic, automation, dal, design-system, embed, novui, shared, shared-web, testing, novu, novu-labs, client, echo, headless, nest, node, notification-center, angular-workspace, notification-center-angular, notification-center-vue, providers, stateless.