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]

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)

[condar-metacell]

I don't know how I'd go about adding that to the requirements.txt file. The cloud harness modules aren't on pip, so I can't just have cloudharness-django in there, and the path to them is not well defined; they're at /libraries/cloudharness-django in the base image, but that isn't necessarily going to always be true, and definitely won't be true for running it outside the image.

[ddelpiano]

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

[filippomc]

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

we are not adding inside dependencies on requirements.txt as they don't add anything to the install process there, I think it's fine to leave this one without as long as it's coherent with the rest