Refactor Proteus Conversation Creation Handlers and Drop Managed Conversations

[mdimjasevic]

This PR does a couple of refactorings:

• It unifies endpoint handlers for Proteus conversation creation for a regular group conversation and for a team conversation into a single function,
• Managed conversations are dropped altogether as they are not used at all. As a consequence, an internal endpoint for creating a managed conversation no longer exists.

Follow up work: drop the managed column from the team_conv table in Galley in a few-months time.

Deleted endpoints

This endpoint was not used, and has been deleted:

• POST /i/conversations/managed

Checklist

• The PR Title explains the impact of the change.
• The PR description provides context as to why the change should occur and what the code contributes to that effect. This could also be a link to a JIRA ticket or a Github issue, if there is one.
• If HTTP endpoint paths have been added or renamed, the endpoint / config-flag checklist (see Wire-employee only backend wiki page) has been followed.
• changelog.d contains the following bits of information (details):
  • A file with the changelog entry in one or more suitable sub-sections. The sub-sections are marked by directories inside changelog.d.
  • If internal end-points have been added or changed: which services have to be deployed in a specific order?

[jschaul]

Open question: can we drop the managed column from the team_conv table?

TL;DR: Yes, but not in this PR, but in a separate PR only opened once this PR 2125 has made its way to master and deployed to production (and possibly deployed to customers)

Context: Doing so (i.e. introducing a schema migration that drops this column inside this PR) would be a backwards incompatible change, which would lead to the problems outlined in https://github.com/wireapp/wire-server/blob/develop/docs/developer/cassandra-interaction.md#backwards-incompatible-schema-changes

What this PR should be doing which as far as I can see it does not yet do, is stop writing and reading the managed attribute from cassandra. i.e., change the cql statements here and here to stop taking the managed attribute. Doing this will allow a future PR (in a few weeks or month's time) to introduce an ALTER TABLE team_conv DROP managed. You can leave a FUTUREWORK somewhere linking back to this PR and/or comment and/or the cassandra doc.

If you're not sure if clients might parse the managed attribute at the API level, you can leave it in at the API level (always False).

Thanks for this! +166 -609 is great! 🚀