ENH: add result_type_false: check the minimum promotion rules according to the spec

[ev-br]

https://data-apis.org/array-api/latest/API_specification/type_promotion.html#type-promotion specifies the minimum required promotion rules, and states that

A conforming implementation of the array API standard may support additional type promotion rules beyond those described in this specification.

array_api_strict only allows this minimal promotion rules. So, add a test that promotions beyond this minimum set are not allowed. The test is mostly informational: an array provider may want signal that it allows extra promotion paths by xfailing the test.

[ev-br]

This PR is basically to

• gauge the feeling towards this sort of tests. I think it makes sense to use the test suite to sort of document all sorts of deviations from the strict spec, including where array provider libs extend the standard, not only where they lack something that standard stipulates;
• ask for a review of the added hypothesis strategy

[rgommers]

So, add a test that promotions beyond this minimum set are not allowed.

This feels wrong to me. This test suite should not start including tests for behavior that is allowed by the standard (and common in practice), but just not standardized. That just leads to a lot of busywork I think?

[asmeurer]

I agree this test doesn't make sense. We could use something like this in array_api_strict when testing strictness. Currently those tests don't use hypothesis, but rather just test each combination.

As far as the strategy, it looks like it would do what it says it does. I don't understand the max_size parameter that does nothing. Also, to be fully complete, it would need to include uint64. Maybe a cleaner way to implement it would be to take all possible combinations of dtypes, remove the ones that are promotable, and sample_from that. (but again, I don't know that we actually need this strategy)

[ev-br]

I still think it's a not totally invalid approach, the decision is only where the documentation is, here or in the array libraries. But okay, the reaction is pretty clear :-). Let's close this. Thanks for the review!

[rgommers]

the decision is only where the documentation is

It's more than that. Note that "should" and "must" have precise meanings, see the discussion at data-apis/array-api#796 (we should really close that issue by clarifying the docs). The test suite by design has to verify all the "must" requirements, but not enforce "should" recommendations like they are "must" requirements, nor enforce things that aren't specified.

In the case of type promotion rules, the spec lays out what must be implemented and nothing else. It says:

"Mixed integer and floating-point type promotion rules are not specified because behavior varies between implementations."

If it had said something like "mixed integer and floating-point ... must raise" or "...must not be implemented" then it needs a test like this. In the absence of that language, it doesn't.