Revisit rail creation & operator permissions

[Stebalien]

At the moment, rails are created by the operator contract. This is convenient as it means the client can:

1. Create a single logical deal.
2. Submit that single deal to various service contracts.
3. Have those service contracts create the necessary rails.

All in one step.

Furthermore, it makes it possible for the service contract/operator to create rails asynchronously without the involvement of the client. E.g., the client hands their data over to some intermediary and signs some deal intent, but then walks away and lets the intermediary work with the service contract to establish the actual rail once some yet-unknown SP takes the deal.

However, there's one key downside: control. The client can limit the damage an evil/broken operator can do by limiting the allowances they give to the operator however:

1. Managing these allowances is overhead so I expect clients will set them pretty high.
2. The operator contract maintains quite a bit of control here which could have legal implications (e.g., if some group retains the ability to upgrade the operator contract).

An alternative approach is to have the client create all payment rails, configuring some maximum rate/lockup per rail. The operator would then be allowed to:

1. Increase/decrease the rate within the maximum rate.
2. Pay out one-time payments out of some fixed lockup specified by the client.

The client would be allowed to:

1. Add to the fixed lockup.
2. Increase the maximum payout rate.
3. Terminate the rail.

Under the covers, this would behave mostly the same way as the current design, just with slightly different rules on who can do what.

---

An alternative is to fix all this with more abstraction: stick a contract in-between the upgradable contract and the payment contract.

1. The operator/allowance model stays the same.
2. The intermediate contract acts as the main operator, delegating rail creation permissions to the client and rate-increase permissions to the "real" operator.

Unfortunately, this increases complexity and doesn't do away with the allowance. On the other hand, we can probably hide a lot of the details from the user here.

[aarshkshah1992]

@Stebalien Do we really need this ? I do like the idea of the client having more control on how much they pay out but this does place more sync responsibilities on the client to create and maintain the rail and so a more involved UX for them.

It does simplify the integration though. Operator can assume/verify a rail with the requisite allowance exists before they start providing the requested service.

[Stebalien]

I think we leave it the way it is for now, I just started this as a discussion. Honestly, I think the "abstraction" comment at the end kind of solves it. Effectively, someone who wants less control can protect themselves by deploying this highly restricted operator "proxy" contract and therefore reduce their ability to mess with client funds (at the expense of slightly worse UX).