enums: refactor BorrowerDocumentType as document_type table

[yolile]

Following from #362 (comment) we could consider having a settings table where we put all the current enums instead of hard coding them. This is especially relevant for document types, as lenders can request for new types when they are onboarded. The table should be fine for now but in the future we could also consider adding a form on the OCP admin page for managing settings.

[jpmckinney]

Enums with no associated logic (and that have demand for configurability) can be made into tables (and even associated with specific lenders, if e.g. not all document options should be available for applications to all lenders). This includes:

• BorrowerDocumentType (note: there is some logic specifically for SIGNED_CONTRACT)
• BorrowerSector (didn't exist in backend until fix: Fix translation of application status. feat: Add BorrowerSector. Use gettext to translate enums. #382)

Another option, instead of putting these entirely in the DB, is to have a "main list" with all options as a enum, and then a Lender has a JSON field or similar to limit the options. (This option is only interesting if we want to change the least code.)

---

Most enums are central to application logic, so they should probably remain enums:

• ApplicationStatus
• BorrowerStatus
• MessageType
• UserType
• ApplicationActionType
• CreditType
• BorrowerType (no logic at the moment, but see Implementation notes: Changes needed if we have products for natural persons #372)

Some related only to statistics, that are less important (but also less demand for configurability?):

• BorrowerSize
• StatisticType
• StatisticCustomRange

[yolile]

Enums with no associated logic (and that have demand for configurability) can be made into tables (and even associated with specific lenders, if e.g. not all document options should be available for applications to all lenders).

Agree

Most enums are central to application logic, so they should probably remain enums:

Agree

Right now we need to add a new document type for one lender, so I will prioritize this issue.

Statistic* will probably disappear anyway (as part of #322)

BorrowerSize is related to lender/credit products so it could be a good candidate for the table option

[yolile]

Right now we need to add a new document type for one lender, so I will prioritize this issue.

As I won't have time to implement this before I'm back I did #396 for now (but with #362 implemented at least I didn't have to touch also the front end to add the new type)

[yolile]

After thinking more about this, I think we probably only need a document_type table, with a document description and name (and code). Currently, credit_product has required_document_types, which is a JSON of document type and boolean values pairs. I guess we could keep that and in the front end query the document's description and names based on the code. With this approach at least we won't need to redeploy the backend only to add new document types.

[jpmckinney]

Sounds good to me!