Salesforce destination split out

[pauloouriques]

Change description

This PR contains the most common usages of the Salesforce destination split out into separated destinations.

Checklists

Development

• Application changes have been tested appropriately

Impact

• Code follows company security practices and guidelines
• Security impact of change has been considered
• Performance impact of change has been considered
• Possible migration needs considered (model migrations, config migrations, etc.)

Please explain any security, performance, migration, or other impacts if relevant:

Code review

• Pull request has a descriptive title and context useful to a reviewer. Screenshots or screencasts are attached where applicable.
• Relevant tags have been added to the PR (bug, enhancement, internal, etc.)

[bleonard]

Looking good. I think there's some tactics to shred more code and make it more declarative as noted.

[bleonard]

👍

[bleonard]

This method is almost exactly the same as the -contacts (and -objects?) one. That's true for many of these files.
I feel like there is an oppurtunity have a meta concept where you pass what's important (model defaults, known special fields to a single method (or maybe one each) and get back all the methods that implement the destination. TSo the desitnation-specific code would all be in connection.

See how app-templates buildConnection is used here:
https://github.com/grouparoo/grouparoo/blob/main/plugins/%40grouparoo/postgres/src/lib/table-import/connection.ts

export function getConnection() {
  return buildConnection({
    apps: ["postgres"],
    name: "postgres-import-table",
    displayName: "Postgres Table Import",
    description: "Import or update Records from a Postgres database table.",
    tableOptionDescription: "The table to scan",
    getSampleRows,
    getColumns,
    getTables,
    getChangedRows,
    getPropertyValue,
    getPropertyValues,
    getChangedRowCount,
  });
}

[bleonard]

Good work!