Make get_differential_vars type stable

[Ickaser]

Checklist

• Appropriate tests were added
• Any code changes were done in a way that does not break public API
• All documentation related to code changes were updated
• The new code follows the
  contributor guidelines, in particular the SciML Style Guide and
  COLPRAC.
• Any new documentation only uses public API

Additional context

Solves #2594 , based on #2594 (comment).

Question on testing

It seems like a good idea to add a test that would have caught #2594; my attempt would be to add @inferred in a couple places. Would

OrdinaryDiffEq.jl/lib/OrdinaryDiffEqRosenbrock/test/dae_rosenbrock_ad_tests.jl

Lines 31 to 42 in cc958fb

	@testset "Inplace: $(isinplace(_prob)), DAEProblem: $(_prob isa DAEProblem), BrownBasic: $(initalg isa BrownFullBasicInit), Autodiff: $autodiff" for _prob in [
	prob_mm, prob_mm_oop],
	initalg in [BrownFullBasicInit(), ShampineCollocationInit()], autodiff in [true, false]
	alg = Rodas5P(; autodiff)
	function f(p)
	sol = solve(remake(_prob, p = p), alg, abstol = 1e-14,
	reltol = 1e-14, initializealg = initalg)
	sum(sol)
	end
	@test ForwardDiff.gradient(f, [0.04, 3e7, 1e4])≈[0, 0, 0] atol=1e-8
	end

or

OrdinaryDiffEq.jl/lib/OrdinaryDiffEqBDF/test/dae_ad_tests.jl

Lines 14 to 37 in cc958fb

	p = [0.04, 3e7, 1e4]
	u₀ = [1.0, 0, 0]
	du₀ = [-0.04, 0.04, 0.0]
	tspan = (0.0, 100000.0)
	differential_vars = [true, true, false]
	prob = DAEProblem(f, du₀, u₀, tspan, p, differential_vars = differential_vars)
	prob_oop = DAEProblem{false}(f, du₀, u₀, tspan, p, differential_vars = differential_vars)
	sol1 = solve(prob, DFBDF(), dt = 1e-5, abstol = 1e-8, reltol = 1e-8)
	sol2 = solve(prob_oop, DFBDF(), dt = 1e-5, abstol = 1e-8, reltol = 1e-8)
	# These tests flex differentiation of the solver and through the initialization
	# To only test the solver part and isolate potential issues, set the initialization to consistent
	@testset "Inplace: $(isinplace(_prob)), DAEProblem: $(_prob isa DAEProblem), BrownBasic: $(initalg isa BrownFullBasicInit), Autodiff: $autodiff" for _prob in [
	prob, prob_oop],
	initalg in [BrownFullBasicInit(), ShampineCollocationInit()], autodiff in [true, false]
	alg = DFBDF(; autodiff)
	function f(p)
	sol = solve(remake(_prob, p = p), alg, abstol = 1e-14,
	reltol = 1e-14, initializealg = initalg)
	sum(sol)
	end
	@test ForwardDiff.gradient(f, [0.04, 3e7, 1e4])≈[0, 0, 0] atol=1e-8
	end

be a good place for these? Should this get tested with all the implicit solvers where the mass-matrix DAE formulation is allowed?

[ChrisRackauckas]

be a good place for these?

Yeah, the more the marrier.

https://github.com/SciML/OrdinaryDiffEq.jl/blob/master/test/interface/mass_matrix_tests.jl is probably a good test to slam some around.

[Ickaser]

Turns out that lots of these are still not inferrable--even with this PR, going from Rosenbrock DAE AD tests, the move from

sol = solve(prob_mm, Rodas5P(), reltol = 1e-8, abstol = 1e-8)

to

using ADTypes: AutoForwardDiff
sol = @inferred solve(prob_mm, Rodas5P(autodiff=AutoForwardDiff(chunksize=3)), reltol = 1e-8, abstol = 1e-8)

already runs into an issue, since the type of solve is still inferred to be Any. I think there is something else going on here (or I don't know how to use @inferred properly, which is possible), but I can't tell what makes this different from the MWE I've been testing against.

That said, even though this PR apparently doesn't do enough for the existing test suite, it is already helping with the MWE and therefore probably my code base.

[ChrisRackauckas]

It's fine to sprinkle some @test_brokens around to get things in, and document them.