feat: Abstracted content engine

[Swahjak]

What change does this PR introduce?

Initial thoughts on how the content engine might be abstracted to allow it to be extended / replaced.

Why was this change needed?

Closes #2002

Other information (Screenshots)

[p-fernandez]

Good abstraction. Besides a pair of comments you would also need to update the test file: https://github.com/novuhq/novu/blob/2d3050a13b5dfc77b0d66e34ed2eac8a25299631/packages/stateless/src/lib/content/content.engine.spec.ts that is dependant in the changes you are proposing.

[Swahjak]

Good abstraction. Besides a pair of comments you would also need to update the test file: https://github.com/novuhq/novu/blob/2d3050a13b5dfc77b0d66e34ed2eac8a25299631/packages/stateless/src/lib/content/content.engine.spec.ts that is dependant in the changes you are proposing.

Didn't get to that just yet, but I will update the tests as well. Thanks for the review, I'll try and update the PR in the upcoming week 👍

[Swahjak]

@p-fernandez to what extend, and especially in which files, should I test the ability to change the engine? Should I add tests to both the email and sms handler (spec)? I already updated the content.engine.spec.ts.

[p-fernandez]

@p-fernandez to what extend, and especially in which files, should I test the ability to change the engine? Should I add tests to both the email and sms handler (spec)? I already updated the content.engine.spec.ts.

Not sure if I understood you correctly but I do not think you should test what happens if changing the engine (moving from Handlebars to a different library).
If you meant if you have to test changes in email.handler.ts and sms.handler.ts, I consider it shouldn't be needed to do anything extra, as the current tests implement the templating functionality and your changes will be validated if they still pass as they are.

[p-fernandez]

🌟