Further restrict proxy account ordering

[ghost]

As a follow up from #712, further restrict the proxy account through in-pallet state. Limit properties like for which parathread an account can order a core and how often (e.g. once per hour, once per day, unlimited, ..)

This will need to be setup by the user via an extrinsic. Parathread security opt in would look like that:

1. No security - just use a hot account. Might be fine for some cases or if only holding a small amount of DOT ...
2. Use proxy account limited to ordering parathread cores - can still be any parathread, but at least no balance transfers or other stuff.
3. Send extrinsic to parathread assignment provider pallet to restrict access from a given account, restrictions that come to mind are listed above.

Implementation

Provide call/extrinsic to set further restrictions on an account

Something like:

struct AccountRestriction {
  /// Allowed paraids the account can place orders for.
  /// `None` means no restriction.
  allowed_paraIds: Option<Set<ParaId>>,

  /// How many blocks since the last enqueued order must have passed for a new order to be accepted.
  /// `None` means no restriction.
  allowed_frequency: Option<BlockNum>,
}

fn restrict_account(Origin, AccountId, AccountRestriction);

Obvious problem, which account is allowed to place restrictions on another account? Setting restrictions will only be possible for proxy accounts and the restricting account has to be the proxied account.

We need to charge the calling account not only weight based fees, but also need to take some deposit for the storage.

If set_account_restrictions is called with all restrictions set to None we remove the restriction from state all together - see next section.

Enforcing restrictions

We will need to store current restrictions in a map per AccountId, which we then need to look up whenever an order is queued. For the allowed_frequency requirement we will also need to store the block number of the last placed order for that account.

[eskimor]

With credits, theoretically still useful, but also likely overkill. Closing.