Problematic orders can be created through the order add form by merchants

Describe your bug or feature request.

We've had multiple production issues all involved with merchants using the admin order add and edit form. I thought I wrote about these issues we experienced in the last 4 years in production, maybe it helps building a better OOBE for devs and users.

We manage webshops in EU, so European Union VAT tax is almost always used for orders. So before trying to replicate the issue make sure to create a store which "Tax registrations" is for example "Slovakia", and adding "European Union VAT" tax type (meaning 20% VAT usage).

1. Taxes are wrong if merchant starts adding order level adjustments

Common use case for this is a customer calls the shop if X product can be ordered. The answer is yes but sometimes there's a possibility to order a cheaper X product which was returned by someone else before and is sold at lower price. Usually, merchants don't create a new product or variation with that price, they just create a draft order on the admin form, add the product (in this example its price is 9.99 EUR), and they see the Adjustments form widget, so there they fill -3 EUR with label "Discount" and send the order in the name of the customer.
With this, the following is saved for the order:

Subtotal €9.99
discount -€3.00
VAT €1.67
Total €6.99

This is completely wrong because 6.99-6.99/(1+20/100) = 1.165, so the VAT is now at invalid value (I think it still calculates from the original price 9.99-9.99/(1+20/100) = 1.665). Usually no one notices that until there's bookkeeping and tax declaration, where we see that multiple things were sold at higher VAT rate than it should be. And the sent invoices are wrong.

I propose hiding that Adjustments form field by default because if no valid value can be set there by users, then they should not mess around with that.

2. Sellers forget they can't edit orders after it was sent, and still go to order edit page and mess up everything

Typical use case: customer ordered something, but mistyped the quantity, or adding one more product to the order before paying it with bank transfer. If we enable for them to edit orders, they will open order item, edit the quantity and save. After that, again, the taxes are not recalculated. They can't even fix these taxes as order item adjustments can't be displayed on the form by default. We once enabled that field to edit there:

function order_edit_entity_base_field_info(EntityTypeInterface $entity_type) {
  if (in_array('Drupal\commerce_order\Entity\OrderItemInterface', class_implements($entity_type->getOriginalClass()))) {
    $fields['adjustments'] = BaseFieldDefinition::create('commerce_adjustment')
      ->setLabel(t('Adjustments'))
      ->setRequired(FALSE)
      ->setCardinality(BaseFieldDefinition::CARDINALITY_UNLIMITED)
      ->setDisplayOptions('form', [
        'type' => 'commerce_adjustment_default',
        'weight' => 0,
      ])
      ->setDisplayConfigurable('form', TRUE)
      ->setDisplayConfigurable('view', FALSE);

    return $fields;
  }
}

but they still didn't understand that they need to fix these at the order item level.

What's more problematic is when commerce_shipping is also used, they are trying to change shipping method there, they start to rewrite prices and again, and since data about shipping is saved to multiple entities, they start to mess around with those resulting invalid prices and discounts in the order.

I propose disabling order edit possibility by default. That causes too much trouble for everyone. Sometimes as devs we can't even tell what they messed up until we take a database dump from production and look into database tables. It's much easier to tell that if they need to change the order, cancel that (we had t modify the order workflow, so already completed orders can be cancelled in case of money return or when user sent back the product) and create a new instead in checkout.