Handle zero on arrays of unions of number types and missings

[oxinabox]

I believe this resolves #53582

The intent of #51458
was to only change cases that were errors into successes.
(or in case of undef elements into different errors)
Not to change behavour of any existing non-erroring code.

This particular interaction was the result of the existance of

 [19] zero(::Type{Union{Missing, T}}) where T
     @ missing.jl:105

Which only uses the T to determine the zero, not the whole type.
Which could not be replicated by iterting over the elements, as those all have concrete types.
This just pushed that check up to also happen at the AbstractArray level.
Which isn't particularly satifying, but does fix the issue, and I suspect all similar cases that actually exist in the wild.
(I will note that we do not require the same for nothing as that does not have a similar zero(Union{Nothing, T}) overload.)

Possibly there are other cases involving Vector{T}(undef,...) that also now error, which this PR does not fix.
These would exist if there is a non-isbits type that implements zero{T}, but which does not implement zero(::AbstractArray{T}), of which AFAICT there are none in Base from looking at methods zero.
In general arrays containing undef break for a ton of operations, so I didn't worry about them to much in the original PR.

[oxinabox]

Arguably this should be:

Suggested change

	zero(x::AbstractArray{S}) where {T<:Number, S<:Union{Missing, T}} = fill!(similar(x, typeof(zero(S))), zero(S))
	zero(x::AbstractArray{<:Union{Missing, T}}) where {T<:Number} = fill!(similar(x), zero(T))

which would mean that you continue to get back a type which can be mutated to hold missings.
However that is not the behavour of 1.10.
So I didn't do that.

[oxinabox]

Weirdly this doesn't seem to solve the issue for the actual OP of

Even though it does for the seemingly identical case in the tests and for the second comment on that issue

julia> @which zero(Vector{Union{Quantity{Float64, 𝐋}, Missing}}(undef, 1))
zero(x::AbstractArray)

julia> @which zero(Vector{Union{CustomNumber, Missing}}(undef, 1))
zero(x::AbstractArray{S}) where {T<:Number, S<:Union{Missing, T}}

And I am blanking on why.
Since

julia> Quantity{Float64, 𝐋} |> supertype |> supertype
Number

[oxinabox]

arguably we do not need this, since the error is replicated with just the Union{Float64, Missing} case above

[vtjnash]

[19] zero(::Type{Union{Missing, T}}) where T @ missing.jl:105

This is not the correct way to write this (it fails the need_to_handle_undef_sparam test, though we mark it as test_broken there). The correct way (with corrected sparam handling and usually better morespecific precedence) seems to be:

zero(::Type{T}) where {T>:Missing} = zero(nonmissingtype_checked(T))

This likely also needs to still specifically handle zero(Any) calls, since "could not compute non-missing type" is not the most useful error message:

zero(::Type{Any}) = throw(MethodError(zero, (Any,)))

The method here is similarly then possibly:

zero(x::AbstractArray{T}) where {T<:Union{Missing,Number}} = fill!(similar(x), zero(T))

[oxinabox]

Should I go and change all of these:

julia/base/missing.jl

Lines 103 to 116 in 90d84d4

	for f in (:(Base.zero), :(Base.one), :(Base.oneunit))
	@eval ($f)(::Type{Missing}) = missing
	@eval function $(f)(::Type{Union{T, Missing}}) where T
	T === Any && throw(MethodError($f, (Any,))) # To prevent StackOverflowError
	$f(T)
	end
	end
	for f in (:(Base.float), :(Base.complex))
	@eval $f(::Type{Missing}) = Missing
	@eval function $f(::Type{Union{T, Missing}}) where T
	T === Any && throw(MethodError($f, (Any,))) # To prevent StackOverflowError
	Union{$f(T), Missing}
	end
	end

Seems like a seperate PR?

[vtjnash]

Seems worth doing, though yes, as a separate PR probably

[KristofferC]

Does Unitful pass after this PR (or at least the previous errors relating to this are no longer there)?

[oxinabox]

It does not, see:
#53602 (comment)

[vtjnash]

Could we make this a map_defined(zero, x) where mapdefined is the same as map, but adds an isdefined check in the _collect loop? Seems like we might need to define a isdefined(::Generator) check and then a iterateskip(::Generator) function for that?

[oxinabox]

we could.
My thoughts on that when i initially did this was that it wasn't worth doing.
Because in the greater context of why you are callign zero on a AbstractArray,
you are doing linear algebra.
And other linear algebra operations like + and scalar multiplication, also error when you do them on an array containing any undefined elements.