`OrderStorage::createWithSampleValues()` should create stub for payment_method

Adding similar issues from Commerce

This change doesn't look right... There is no payment_method field if there is no payment module enabled? The payment_method field is added as a base field by the commerce_payment module.

Ah good catch, I need to add a conditional in there. This was just my quick-and-dirty from my local project.

Or perhaps the right fix is to just set a query_access handler?

Re: #7, @jsacksick and I chatted a bit via DM. That would also be a potential way to address this, though I am curious about the very Commerce-y angle of the fact that many payment methods are "owned" by the anonymous user, and so filtering by the current user (who could likely be anonymous?) would need to be addressed. I suppose we could further special-case that, but that would perhaps create a hard-to-debug condition for people legitimately trying to do the thing we are special-casing.

I might be wrong but isn't this a bug in \Drupal\Core\Field\Plugin\Field\FieldType\EntityReferenceItem::generateSampleValue() shouldn't that respect the target_bundles set in the field too? Or have I misunderstood the bug?

@jsacksick explained that I am wrong. What we need to do here is alway generate a new payment method. I think making this change here is fine. Maybe add a todo to try to do this with access control but I think that that is going to be hard.

I also think a comment explaining why this is being done would be great.

One thing I was wondering, should we dispatch an event so we can set the payment_method from an event subscriber that lives in commerce_payment? Also createWithSampleValues() isn't static (at least the parent method isn't). If we don't go with the event, I guess we should go with a moduleExists() check (ofc less elegant).

Working on this further, I believe commerce_payment has the same issue as it also references a payment method. One wrinkle there, however, is that it doesn't appear there's any code path to restrict the payment method type that can be placed on a payment? Do we need a way for payment types to convey what types of payment methods may be used, so we can accurately create a sample value?

Answering my own question, methods and payment types are restricted by the gateway in use. So creating a sample value should draw on that context, if available. Rubber-ducking: https://drupal.slack.com/archives/C1TLCCF9B/p1719209765390819

OK, I updated this to handle a similar issue with sample payment entity creation. Ended up adding a mapper to the payment gateway plugin manager to find a gateway that supports a given payment type/payment method type pair. Which is a nice little DX improvement.