Re-introduce Array API Tests suite

[prady0t]

• ☑️ I understand it is strictly prohibited to use AI to write PR description
• AI usage disclosure: Some parts were written using GitHub Copilot

Following #3526, we are in a much better shape to re-introduce the array-api-tests in CI.

[prady0t]

Please allow gh-action runs for this PR so we can see failures in CI.

[prady0t]

CC @ev-br

[ev-br]

One small suggestion below.

The first run is expected to have a few failures. Once we see them, we'll be able to produce a set of relevant skips.

[prady0t]

@ev-br We need to address this PR data-apis/array-api-tests#459

See error log in CI

Invoked with types: int, kwargs = { device: mlx.core.Device }
ERROR array_api_tests/test_dlpack.py - TypeError: zeros(): incompatible function arguments. The following argument types are supported:
    1. zeros(shape: int | Sequence[int], dtype: Dtype | None = float32, *, stream: StreamOrDevice = None) -> array

[ev-br]

Ah yes. Let's continue on the array-api-tests PR

[prady0t]

@ev-br The test suite now runs. Thanks!

I've tried adding a skip file in the latest commit (which may not be accurate, as I used AI to generate it); let's wait for another CI run.

[ev-br]

Thanks for the ping @prady0t!

IMO the tentative skips file shows that the compatibility level is very high.

To explain some context, which might not be immediately clear for those who do not deal with the Array API test suite regularly:

• the test suite itself mainly checks compatibility with the Array API spec. In particular, value testing it performs is rather limited. Checking correctness of implementations themselves is left to individual projects' test suites.
• the workflow itself is fairly typical for the Array API test suite. Here's the JAX analog: https://github.com/jax-ml/jax/blob/main/.github/workflows/jax-array-api.yml
• the test suite does property testing based on hypothesis. Therefore it is not entirely deterministic! The balance is in its --max-examples pytest switch: increasing the value improves stability and makes the run time longer.
• the skips/xfails file, skips-file= argument and xfail.txt added here is the test suite way of recording known failures. The test suite itself is cross-project, and runs unmodified for torch, jax, numpy, ndonnx and so on; therefore it does not use the standard @xfail / @skip decorators; instead, each project carries its own skipfile.

Having a non-empty skips file is actually expected: for example, here are skipfiles for jax, numpy and ndoonx.

Quickly looking through the skips this PR adds, several classes of failures might be somewhat lower priority:

• multiple array_api_tests/test_special_cases.py failures are what torch labels as "module:nans and infs"--- they probe limiting cases of mathematical functions, exp(+inf) = inf, exp(-inf)=0 etc; No known library implements them all fully;
• array_api_tests/test_linalg.py failures flag mostly missing kernels, especially in the complex plane. Presumably quite hard to implement;
• array_api_tests/test_operators_and_elementwise_functions.py flag several issues with elementwise kernels in the complex plane (potentially related to [BUG] mx.abs / mx.sqrt / mx.log on complex64 are silently wrong on GPU across a third of float32's range #4344 or similar);
• array_api_tests/test_has_names.py failures flag missing top-level functions (signbit, nextafter etc).

We could certainly refactor the xfails file to visually group failures.
We would also be happy to help triaging the failures if it's helpful.
Would you prefer us to open separate issues for individual failures, the groups of failures, just keep them grouped and annotated in the skips file, or something else entirely?

[prady0t]

Can we have another CI run for this PR?