Fix constructor of AutoMTK

[Vaibhavdixit02]

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

I was overloading the constructor in OptimizationBase since the deprecation here wasn't sufficient, leading to re-precompilation. I couldn't find a way to use @deprecated for this so this'll have to do.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (733a26a) to head (7cde295).

Additional details and impacted files

@@            Coverage Diff            @@
##              main       #61   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            6         7    +1     
  Lines           65        75   +10     
=========================================
+ Hits            65        75   +10     

Flag	Coverage Δ
docs	2.04% <0.00%> (-0.53%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[gdalle]

I'll review tomorrow, please wait for me

[Vaibhavdixit02]

Sure

[ChrisRackauckas]

Just needs the maxlog thing and this is good.

[Vaibhavdixit02]

Thanks, I wasn't completely sure what you meant by it in the chat

[Vaibhavdixit02]

I'll wait for @gdalle to take a look to make sure it doesn't affect DI

[gdalle]

I don't see the point of introducing a new object when it's already deprecated, and it doesn't correspond to an actual autodiff backend.
We made a breaking release of ADTypes, a breaking release of OptimizationBase might be coming, we should leverage that instead of trying to minimize breakage by sticking to old patterns.
If you need a shortcut for Symbolics with or without sparsity in OptimizationBase, why not use AutoModelingToolkitDeprecated or something of that sort, which you define yourself?

[gdalle]

The AutoModelingToolkit struct in ADTypes v0.2.7 was as follows, so this is the full API we want to deprecate but with meaningful fallbacks:

ADTypes.jl/src/ADTypes.jl

Lines 151 to 164 in 9f17b82

	"""
	AutoModelingToolkit
	Chooses [ModelingToolkit.jl](https://github.com/SciML/ModelingToolkit.jl).
	# Fields
	- `obj_sparse::Bool = false`
	- `cons_sparse::Bool = false`
	"""
	Base.@kwdef struct AutoModelingToolkit <: AbstractSymbolicDifferentiationMode
	obj_sparse::Bool = false
	cons_sparse::Bool = false
	end

@ChrisRackauckas is right that the deprecation logic wasn't correct, so my last commit fixes it. We still generate a deprecation warning, which will be visible to users if such warnings are enabled, but we fall back on the correct version of the Symbolics backend.
@Vaibhavdixit02 what do you think? I took cues from https://invenia.github.io/blog/2022/06/17/deprecating-in-julia/

[ChrisRackauckas]

Why did you change it back to being incorrect? The point is that there was a version without kwargs before.

[gdalle]

My fallbacks handle every version that there was before, with and without kwargs. Both will give the correct result, but both will be deprecated.
The old struct had a Base.@kwdef and the keywords had default values, but I also take care of the standard struct constructor with positional arguments and no default values.

[ChrisRackauckas]

I didn't see the other dispatch. This should work then.

[gdalle]

Let's wait for Vaibhav to test it locally with OptimizationBase before merging