Django Ninja templates

[condar-metacell]

Closes CH-157

Added support for a django-ninja template when using harness-application and harness-generate. Also refactored the application build process into a more structured process of builder components.

...

To test try generating applications using harness-application -t django-ninja and also using harness-generate servers for that app to see the generates servers and openapi schema.

...

Sanity checks:

• The pull request is explicitly linked to the relevant issue(s)
• The issue is well described: clearly states the problem and the general proposed solution(s)
• In this PR it is explicitly stated how to test the current change
• The labels in the issue set the scope and the type of issue (bug, feature, etc.)
• The relevant components are indicated in the issue (if any)
• All the automated test checks are passing
• All the linked issues are included in one Sprint
• All the linked issues are in the Review state
• All the linked issues are assigned

Breaking changes (select one):

• The present changes do not change the preexisting api in any way
• This PR and the issue are tagged as a breaking-change and the migration procedure is well described above

Possible deployment updates issues (select one):

• There is no reason why deployments based on CloudHarness may break after the current update
• This PR and the issue are tagged as alert:deployment

Test coverage (select one):

• Tests for the relevant cases are included in this pr
• The changes included in this pr are out of the current test coverage scope

Documentation (select one):

• The documentation has been updated to match the current changes
• The changes included in this PR are out of the current documentation scope

Nice to have (if relevant):

• Screenshots of the changes
• Explanatory video/animated gif

[afonsobspinto]

I understand the problem is not caused by this PR but there's a typo in this file:
init_listner should be init_listener. Would it be possible to fix it here?

[afonsobspinto]

Same typo here:
init_listner -> init_listener

[afonsobspinto]

Maybe there's a reason for the renaming but without any context on that my preference would be to keep the more generic name: CLOUDHARNESS_FRONTEND_BUILD instead

[afonsobspinto]

I believe
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "__APP_NAME__.settings")
should actually be:
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "django_baseapp.settings")
since that's the place where the settings are defined

[afonsobspinto]

Would it make sense to have cloudharness and cloudharness_django as dependencies here? Since they are conceptually required to run the application (f.e. they are used in settings.py) cc @ddelpiano

[ddelpiano]

I would expect so. I understand we might need CH repo locally if I am in need of regen the template files or the codefresh pipeline, but if I am purely working on the backend I might not need CH and such dependency should be part of the requirements.txt so that all I need to run the backend is already covered by that. Thanks!

[filippomc]

I agree it's better to be explicit about all the dependencies that are imported, even if they are inherited by the base image (like this case)

[ddelpiano]

requirements.txt is missing ch as dependency since the settings.py of the template requires it.