Cart link doesn't respect Availability Checker

I'm not sure what the correct course of action should be here, to be honest. On the one hand, availability checkers should be respected, but on the other hand, how they are respected can be context dependent.

I believe this is why, for example, the cart manager itself does not check availability before creating an order item. Additionally, I'm pretty sure Commerce only checks availability after the add to cart has occurred via the order processor, but I could be wrong.

In this case, I'd almost suggest we leave the default behavior as is but optionally execute availability checking first, rendering the message upon failure. (The problem is, that message is pretty non-specific ... but it's the best we have atm.)

Generally speaking, the availability system needs work. Will link to this from our internal Commerce channel for discussion in a future breaking release.

1. We not only use the availability manager in the context of the order processor but also in the context of validation constraints. That's what prevents non-available items from being added to the cart.
2. We can replicate the context in the cart links module and use it to validate the order item, in fact if we call validate on the order item, that would trigger the same code/behavior as the add to cart form.

I added MR with a proposal.

If we go this direction, I think we may need a couple of different approaches to messaging.

For on-site usage (i.e., a cart link replacing an Add to Cart form in a catalog page), the default messaging is probably fine, though I think taling about "quantity" where there is no quantity input is awkward at best.

For off-site usage (i.e., a link template used in a Google Ad to "buy it now"), I don't think it makes as much sense to talk about a product generically not being available. I envision something more related to a link, promotion, etc. no longer being active, though even there, I'm not sure we can assume. Other ideas?

The MR adopts the same messaging approach as the standard Add to Cart form. It delegates responsibility to the checker to override the generic message with a more specific one that clearly explains why the item couldn’t be added to the cart.

hm... I guess this approach is ok though we could probably copy what the EditQuantity views field handler is doing:

$violations = $order_item
        ->validate()
        ->filterByFields(array_diff(array_keys($order_item->getFieldDefinitions()), [
          'purchased_entity',
          'quantity',
        ]));

This way we flag only errors for the purchased entity field and the quantity... Thoughts?

I gave some more thought to the proposal in #7. While it makes sense within the scope of the current issue, I believe we should keep the implementation as it is and instead adjust the scope.

In my view, we're aiming to replicate the default behavior of the Add to Cart form—which, like with any other entity type in Drupal, runs validation before creating an order item.

A good example of why this matters: imagine a Commerce site with multiple product types, each tied to its own order item type. Some of those order item types have additional required fields. Full validation ensures we don’t end up creating invalid order items when the Add to Cart form would normally prompt for more data before proceeding.

I'm fine with validating all the fields just like the patch is doing atm.