Seemingly useless calls to an internal bisection algorithm in Bisection, Brent, Ridder and Falsi solvers

[dcourteville]

I was testing all bracketing solvers in BracketingNonlinearSolve with tolerance abstol=0.0 and noticed some strange usage of an internal bisection algorithm (in https://github.com/SciML/NonlinearSolve.jl/blob/master/lib/BracketingNonlinearSolve/src/common.jl) in some solver implementations:

• In Bisection, Brent and Ridder: When the exact root is found, instead of directly returning the solution, the algorithm breaks out of the main loop and call an internal bisection algorithm (which doesn't do anything since it already has the solution).
• In Falsi the internal bisection is called when abs(fm) < abstol, likely for numerical stability but it should return the solution directly if iszero(fm).
• Unless I'm missing something, the internal bisection in common.jl doesn't work since it doesn't check the sign of the midpoint.

I don't know what was the original reason for the internal bisection, but I suggest to

• return the exact solution immediately when found in all algorithms
• remove the calls to the internal bisection in Bisection, Brent and Ridder.
• Fix the internal bisection or use the public Bisection solver in Falsi.

[oscardssmith]

Is this done for chainrules purposes or something? I'm very unclear why this would be the case.

[dcourteville]

I made the changes and it doesn't seem to break anything.

[ChrisRackauckas]

I think it was a forwarddiff think, but these days we have specific forwarddiff overloads so that part isn't really used, might as well just remove it.

[oscardssmith]

fixed by #764