✨ Re-build how authors on news are handled, adding support for "custom authors"

[Macludde]

We have an issue how the "stab" is handled currently, especially with how it is hidden.

The goal: Hide any trace of the "stab" on the website, including, but not limited to, the positions, any stab mandates, all the mandates of any active stab members and old mandates for old stab members. The stab should instead post news articles as "Staben".
Currently "Staben" can post news by posting as their mandate, and in the frontend it's hardcoded to show "Staben" instead.
The issue: Since "staben" is hidden then news articles are broken, and does not show any news articles to for example "nollor".

The fix: Add a new type of author, "CustomAuthor".

CustomAuthor

Contains a name, a nameEn and an image. Examples of CustomAuthors are "Staben" and "The Board", but in the future it could be every commitee etc.
There's also a table using role syntax which declares who can post as which CustomAuthor: dsek.noll.stab for "Staben" and `dsek.styr" for "The Board"

How authors are handled now

The author object on an article is either a Mandate or a Member, in the database it's a foreign key to one of the two tables. Each article has a unique author role. Some article rows will be exactly the same, if they're posted by the same person in the same way, but the reason for this is if an author is modified we can modify the author row directly.

How authors are handled in this PR.

New table called authors. It contains a foreign key to the member who is the actual author (always). Then there are two nullable foreign keys, one to the mandatestable and one to the custom_authors table. There is also an enum type which is either "Member", "Mandate" or "Custom". When articles, it joins the articles table and members table to always include that data, then if the author is a Mandate or a CustomAuthor it does another query to get that data.

Frontend

Fixes has been made to publish an article as any of the possible options, also if you edit an article if will do the same but for the original author member.

The migration

The migration in this PR is a big one. Since the format has changed, what it does is the following:

• Adds new custom_authors table
• Adds new custom_author_roles table
• Adds new authors table, which also includes a temporary table during the migration, storing the article id relevant to the author.
• Gets all articles which were posted by a member, ie NOT published as a mandate. (memberAuthorArticles)
• Gets all articles posted as mandates
• Create author rows for each respective type of author
• Populate the author_id field for each article, using the temporary column in the authors table
  Now the data should have been migrated successfully, finally we:
• Drop the temporary column from the authors table
• Drop the old author_type column on articles and sets the author_id column to be a foreign key.

[Macludde]

To test this PR the seeding data for articles had to be changed, and I opted for generating some "random" data to populate more news articles more easily. This means that the seeded data will not be the same EVERYTIME, and not guaranteed to include all types of CustomAuthors.

[Macludde]

There is also no frontend for adding custom authors, currently we'll just add them manually in the database.

[Macludde]

I have created a database called author_backup in the prod database, in case the migration goes wrong we can manually roll it back. This is not a part of the migration, but instead a manual fix, by design.

[danieladugyan]

Great changes overall that are in line with my goal of allowing committee members more freedom to publish posts as a "Committee" author. There are still some discussions to be had regarding database design and generality.

[Macludde]

@danieladugyan is this good to merge or do we want to rename the tables/entities?

[danieladugyan]

@danieladugyan is this good to merge or do we want to rename the tables/entities?

Let's just merge it, we'll deal with it during Prisma rewrite.

[Macludde]

Must wait to fix new notification stuff for author before merging

[Macludde]

So I changed authors in the following way:

• type is now a generated field from the other column data, meaning it can be queried but not manually inserted
• authors are now used instead of the "from_member" field on notification, which is required for (as of now) new article notifications, but could in the future be used in the same way for events, booking requests etc.
• There is no longer an author row for EACH article/notification, instead multiple entities can link to the same author. When updating (or creating) an author, it checks if a row already exists with the same data and just gets that id, and only if it doesn't already exist it creates it.

I also finally moved over all old calls to "getCurrentUser" and "getMemberFromKeycloakId" to the new "getCurrentMember(ctx)" which uses student_id instead of keycloak_id