Email OTP based verification at registration

[Gastro-Diron]

Proposed changes in this pull request

This PR adds a new configuration to the IS management console to enable the Email OTP based verification. For that the following changes are made.
- Added a new configuration called "ENABLE_EMAIL_OTP_VERIFICATION"
- Seperated the secretKey generation method based on the preferred Channel.
- Added unit test for the new methods introduced.
- Made some changes in the TriggerNotification method to get the template according to configuration.

When should this PR be merged

[Please describe any preconditions that need to be addressed before we
can merge this pull request.]

Follow up actions

[List any possible follow-up actions here; for instance, testing data
migrations, software that we need to install on staging and production
environments.]

Checklist (for reviewing)

General

• Is this PR explained thoroughly? All code changes must be accounted for in the PR description.
• Is the PR labeled correctly?

Functionality

• Are all requirements met? Compare implemented functionality with the requirements specification.
• Does the UI work as expected? There should be no Javascript errors in the console; all resources should load. There should be no unexpected errors. Deliberately try to break the feature to find out if there are corner cases that are not handled.

Code

• Do you fully understand the introduced changes to the code? If not ask for clarification, it might uncover ways to solve a problem in a more elegant and efficient way.
• Does the PR introduce any inefficient database requests? Use the debug server to check for duplicate requests.
• Are all necessary strings marked for translation? All strings that are exposed to users via the UI must be marked for translation.

Tests

• Are there sufficient test cases? Ensure that all components are tested individually; models, forms, and serializers should be tested in isolation even if a test for a view covers these components.
• If this is a bug fix, are tests for the issue in place? There must be a test case for the bug to ensure the issue won’t regress. Make sure that the tests break without the new code to fix the issue.
• If this is a new feature or a significant change to an existing feature? has the manual testing spreadsheet been updated with instructions for manual testing?

Security

• Confirm this PR doesn't commit any keys, passwords, tokens, usernames, or other secrets.
• Are all UI and API inputs run through forms or serializers?
• Are all external inputs validated and sanitized appropriately?
• Does all branching logic have a default case?
• Does this solution handle outliers and edge cases gracefully?
• Are all external communications secured and restricted to SSL?

Documentation

• Are changes to the UI documented in the platform docs? If this PR introduces new platform site functionality or changes existing ones, the changes should be documented.
• Are changes to the API documented in the API docs? If this PR introduces new API functionality or changes existing ones, the changes must be documented.
• Are reusable components documented? If this PR introduces components that are relevant to other developers (for instance a mixin for a view or a generic form) they should be documented in the Wiki.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[Gastro-Diron]

Take this logic out of triggernotification

[Gastro-Diron]

If we need to take this out of the TriggerNotification method then we need to pass this as an additional parameter to the method. If that is OK, I can take this out of the method and add an additional parameter for this method.

[Gastro-Diron]

Check for the canhandle method to which events it can handle

[Gastro-Diron]

The method is used only for the self user registration purpose. So we do not have to remove this logic out of TriggerNotification method.

[pamodaaw]

if we have the same username, TEST_USERSTORE_DOMAIN, TEST_TENANT_DOMAIN_NAME, they are not required to be passed from the data provider. They can be defined in the test method itself

[Gastro-Diron]

There was a similar implementation for a test in lines 212 - 221. I just followed the same implementation for this one as well.