✨ post update collision detection

[kirrg001]

refs #5599

Same as #8328, just for master.
I had to adapt some smaller things like error handling, tests.

If two users edit the same post, it can happen that they override each others content or post settings. With this change this won't happen anymore.

✨ Update collision for posts

• add a new bookshelf plugin to detect these changes
• use the changed object of bookshelf -> we don't have to create our own diff
• compare client and server updated_at field
• run editing posts in a transaction (see comments in code base)

🙀 update collision for tags

• updateTags for adding posts on onCreated - happens after the post was inserted
  --> it's "okay" to attach the tags afterwards on insert
  --> there is no need to add collision for inserting data
  --> it's very hard to move the updateTags call to onCreating, because the updateTags function queries the database to look up the affected post

• updateTags while editing posts on onSaving - all operations run in a transactions and are rolled back if something get's rejected

• Post model edit: if we push a transaction from outside, take this one

✨ introduce options.forUpdate

• if two queries happening in a transaction we have to signalise knex/mysql that we select for an update
• otherwise the following case happens:

  you fetch posts for an update
  a user requests comes in and updates the post (e.g. sets title to "X")
  you update the fetched posts, title would get overriden to the old one

use options.forUpdate and protect internal post updates: model listeners

• use a transaction for listener updates
• signalise forUpdate
• write a complex test

use options.forUpdate and protect internal post updates: scheduling

• publish endpoint runs in a transaction
• add complex test
• @todo: right now scheduling api uses posts api, therefor we had to extend the options for api's

  allowed to pass transactions through it
  but these are only allowed if defined from outside {opts: [...]}
  so i think this is fine and not dirty
  will wait for opinions
  alternatively we have to re-write the scheduling endpoint to use the models directly