Implement Limit Order Modification Feature

[abitmore]

PR for #1604.

Based on @nathanielhourt's work for #1604 (see nathanielhourt#1).

Changes:

• New operation: limit_order_update_operation, so that traders can update their limit orders directly
  • operation_type = 77
  • default fee 0.375 BTS (slightly lower than the current order creation fee on the BitShares Mainnet, and applicable to all refund mechanisms)

   struct limit_order_update_operation : public base_operation
   {
       struct fee_params_t {
           uint64_t fee = ( GRAPHENE_BLOCKCHAIN_PRECISION * 3 ) / 8;
       };
  
       asset fee;
       account_id_type seller;
       limit_order_id_type order;
       optional<price> new_price;
       optional<asset> delta_amount_to_sell;
       optional<time_point_sec> new_expiration;
       /// Automatic actions when the limit order is filled or partially filled
       optional< vector< limit_order_auto_action > > on_fill;
  
       extensions_type extensions;
   };
  

NOTE 1:
The base amount in the new price is limited by an estimation of the order's maximum amount to sell. This is to mitigate against inappropriate price manipulation, although not completely avoid it.

NOTE 2:
When updating a limit order with a non-zero deferred fee, we charge the owner a small fee equal to order_cancel_fee * order_update_fee / order_create_fee (not higher than the deferred fee), and refund the remainder in the deferred fee, the deferred fee is then refreshed with the new operation fee paid.
The small fee is to mitigate potential transaction spam issues.
The deferred fee is used for all refund mechanisms.

Side effect:
Assuming that order update fee will be lower than order creation fee, traders can create an order and then update it immediately to reduce costs, both for making and taking.

NOTE 3:
Since the price can be modified, sell_price.base.amount is no longer always equal to the total amount allocated to the limit order. In the meanwhile, a new data field filled_amount is added to limit_order_object in PR #2776, this way users can still know the total amount.

NOTE 4:
Please see #2749 for more info about automatic actions (Order-Sends-Order).

[sonarcloud]

Please retry analysis of this Pull-Request directly on SonarCloud.