Refactor / move entitlement logic to entitlement controller

[ChristiaanScheermeijer]

Description

This PR is a refactor of the entitlement implementation. This is a bit spontaneous as we didn't plan for this, but a few reasons for this refactor are:

• We updated the generic entitlement service backend to be more simple since the JWP delivery API changes
• The entitlement logic was spread over too many components
• The useProtectedMedia and useContentProtection hooks contained too much logic
• The contentSigningService config property is not usable with JWP app configs

In short, I have made the following changes:

• Add a new EntitlementController class to house most of the entitlement logic from the hooks
• Move the entitlement implementations to a subfolder and extend it from an abstract Entitlement class
• Updated the GenericEntitlement API request and activation condition to config.custom params
• Added unit tests for the EntitlementController logic

After rebasing with develop I noticed that these changes conflict with #654. So I fixed that bug in this PR as well, so this PR now supersedes #654 now.

[github-actions]

Visit the preview URL for this PR (updated for commit 3784aa3):

https://ottwebapp--pr657-refactor-entitlement-xiy81jvu.web.app

_{(expires Sat, 04 Jan 2025 13:27:37 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

_{Sign: c198f8a3a199ba8747819f7f1e45cf602b777529}

[langemike]

Nice step forward by moving most logic from the useContentProtection and useProtected hooks to a EntitlementController class, which also potentially can be overridden.

I have no feedback on the code. Looks good!

[ChristiaanScheermeijer]

I was looking at the failing e2e tests and found a typings issue in the module system.

For integrations, we use the getNamedModule function to dynamically inject the requested integration service. However, when no integration is configured, this call results in getNamedModule(AccountService, null);, but the return type remains concrete. This means we wrongfully assumed that the integration services were always set.

This currently isn't causing any bugs because we basically never call these methods when no integration is configured, but this is not good practice and did cause an error in this PR which could have been prevented with the correct typings.

In my last commit I have made most injected integration services optional which, after doing so, resulted in many TS errors. But these could all be solved by adding the assertModuleMethod util like we already did for some occasions.