Uniformize datasources

[charlesBochet]

Context

We recently enabled the option to bypass SSL certificate authority validation when establishing a connection to PostgreSQL. Previously, if this validation failed, the server would revert to unencrypted traffic. Now, it maintains encryption even if the SSL certificate check fails. In the process, we overlooked a few DataSource setups, prompting a review of DataSource creation within our code.

Current State

Our DataSource initialization is distributed as follows:

• Database folder: Contains 'core', 'metadata', and 'raw' DataSources. The 'core' and 'metadata' DataSources manage migrations and static resolver calls to the database. The 'raw' DataSource is utilized in scripts and commands that require handling both aspects.
• typeorm.service.ts script: These DataSources facilitate multi-schema connections.

Vision for Discussion

• SystemSchema (formerly core) DataSource: Manages system schema migrations and system resolvers/repos. The 'core' schema will be renamed to 'system' as the Core API will include parts of the system and workspace schemas.
• MetadataSchema DataSource: Handles metadata schema migrations and metadata API resolvers/repos.
• (Dynamic) WorkspaceSchema DataSource: Will be used in the Twenty ORM to access a specific workspace schema.

We currently do not support cross-schema joins, so maintaining these DataSources separately should be feasible. Core API resolvers will select the appropriate DataSource based on the field context.

• To be discussed: The potential need for an AdminDataSource (akin to 'Raw'), which would be used in commands, setup scripts, and the admin panel to connect to any database schema without loading any model. This DataSource should be reserved for cases where utilizing metadata, system, or workspace entities is impractical.

In This PR

• Ensuring all existing DataSources are compliant with the SSL update.
• Introducing RawDataSource to eliminate the need for declaring new DataSource() instances in commands.

[charlesBochet]

@magrinj @Weiko FYI, would be great to know your thought on that

[charlesBochet]

this datasource is not used as we have disable the 1 datasource per workspace pattern which we would need if we want to introduce 1 user per workspace (pg_graphql needs it for performance + great for security/privacy). Likely to be deprecated mid term with twenty orm effort