🐛 Bulk adding tags created "duplicate" posts_tags rows from editor posts page

[Navarjun]

#21414
The commit includes a migration which adds a unique index to posts_tags table and handles the related error when bulk adding posts.

The DB errors of duplicate insertions (for unique index) are ignored because the tags user wants to add are added/exist. This respects the editor's expectation as posts have the tags as the end result.

[github-actions]

It looks like this PR contains a migration 👀
Here's the checklist for reviewing migrations:

General requirements

• Satisfies idempotency requirement (both up() and down())
• Does not reference models
• Filename is in the correct format (and correctly ordered)
• Targets the next minor version
• All code paths have appropriate log messages
• Uses the correct utils
• Contains a minimal changeset
• Does not mix DDL/DML operations
• Tested in MySQL and SQLite

Schema changes

• Both schema change and related migration have been implemented
• For index changes: has been performance tested for large tables
• For new tables/columns: fields use the appropriate predefined field lengths
• For new tables/columns: field names follow the appropriate conventions
• Does not drop a non-alpha table outside of a major version

Data changes

• Mass updates/inserts are batched appropriately
• Does not loop over large tables/datasets
• Defends against missing or invalid data
• For settings updates: follows the appropriate guidelines

[Navarjun]

@kevinansfield @ErisDS @cathysarisky I have created a PR for this bug.
Please take a look and let me know if any changes are required.

I did 2 things:

1. Created a migration to add a unique index to post_id and tag_id
2. Updated the #bulkAddTags table to avoid duplicates without throwing an error. Essentially, it will ignore any conflicts because of duplication.

Please merge it soon, if you find it worthy.

[ErisDS]

Heya, thanks for putting this together 🙏

Irreversible migrations can only be run in a major update, as they're effectively a breaking change. I would actually expect that to be enforced, and for CI to fail on this PR 🤔 Seems we're missing a check.

It would also be necessary to write a migration that cleans up any existing duplications, otherwise this migration will fail for anyone who has already run into this.

These migrations would need to live in ghost/core/core/server/data/migrations/versions/6.0 and be held back on a branch until such time as we cut the major.

Not sure if there's maybe an alternative fix for the short term?

Especially considering this is not only related to #21414 but also to #19871, which needs a UI-based fix I think.