RAS-1400 use native sql

[LJBabbage]

What and why?

The code in the model https://github.com/ONSdigital/ras-party/blob/main/ras_party/models/models.py#L40 will force join the attributes table, due to how we create business attributes for every individual sample entry, means there are literally thousands for some businesses. Because of that if we attempt any join using the Business model it will overwork and produce an excessive performance hitting amount of joins. This PR sides steps the model and creates a pure SQL of exactly what we want

How to test?

Create enrolments for different CE's and make sure when you log in the correct information is displayed on the todo list. You can use acceptance-tests, but I would add another enrolled to them and possible another CE

Jira

[SteveScorfield]

/deploy scorfs

[ras-rm-pr-bot]

Deploying to dev cluster with following parameters:

• namespace: scorfs

• tag: pr-450

• configBranch: main

• paramKey: ``

• paramValue: ``

[SteveScorfield]

I have tested the code and works as expected. The acceptance tests pass. I like this approach. It's more streamlined. Approved.

[pricem14pc]

• reviewed code
• tested locally in docker and in dev environments(run time and build) and successfully tested multiple enrollment permutations
• checked cross-app usage of v1/enrolments/respondent is for a limited number of frontstage use cases only
• tested a number of preprod use cases for large enrolments
• native query correctly returning significantly less rows than the inefficient SQLAlchemy query (i.e. no longer outer join to respondent/respondent_business returning rogue rows for other respondents)
• tested the query explain plan and it no longer needs to create expensive hash tables or nested outer joins

[pricem14pc]

Happy with the current improvements and have discussed progressing the outstanding comments at a later date.