Promoter: Make sure only one promoter handles each user

[ro-tex]

Problem

Looks pretty good but what happens when you call the setter on an account managed by stripe or vice versa? e.g. it might be dangerous to have a promoter create a user and manage it but not prevent attaching a stripe subscription to a user.

Originally posted by @ChrisSchinnerl in #242 (review)

Proposed solution

Hmm, you are right. When we first discussed this, I made an assumption about the way the promoter would work. This assumption was that it will get all current user information and work with that in order to determine when to promote and/or demote the user. But that might be too complicated.

How about we give each promoter a unique ID (self-generated UUID) and they would only be allowed to work on users which either don't belong to a promoter or belong to them, specifically? And then when a user's paid period ends, the promoter demoting them to free will remove its ID from them? All of this can be automated by accounts.

All current users with active subscriptions will be set to work with stripe.

All of this will need to happen in a separate issue.

[ro-tex]

the decision reached here is the following:

• a portal can use one of two approaches for payments: Stripe for fiat or Promoter (credit system) for crypto payments
• when using Promoter there can be multiple payment processors attached to it (in theory we can also add a payment processor for Stripe or another fiat provider but there are no current plans for that)
• each portal operator can attach a set of payment processors of their choosing (we should design a user-friendly way to do that)

each payment processor is responsible for:
1. providing a UI (list prices, get a new payment address, etc.)
2. watching for payments on the relevant blockchain
3. converting those payments to credits and reporting those credits to Promoter (e.g. user with sub xyz just paid for 123 credits)
4. handle server failure, etc.

Promoter is responsible for:

1. keeping a tab on the user's credit balance
2. exposing a UI which lets the user control their subscription:
   - which tier they want
   - for how many months they want to pay at a time
   - subscription suspension/restart
   - etc.
3. charging the user each time they need to pay
4. promoting/demoting the user when needed