Bump decimal to 3.x to fix unauthenticated DoS (GHSA-rhv4-8758-jx7v)

[daveshah]

decimal versions < 3.0.0 do not bound the exponent on parsed input, so a value such as "1e10000000" parses fine but then allocates gigabytes of memory during arithmetic, rounding, to_integer/1, or to_string/2. This is an unauthenticated remote DoS for any code path that accepts a user-supplied decimal — see GHSA-rhv4-8758-jx7v (moderate severity, patched in decimal 3.0.0).

mix deps.audit flags the previously locked decimal 2.3.0. The only fix is upgrading to the 3.x line, so the ~> 2.1 requirement is widened to ~> 3.0. This cascades into transitive bumps required for resolution: jason 1.4.4 -> 1.4.5 and adbc 0.7.8 -> 0.12.1, both of which now allow decimal ~> 3.0.

mix_audit is also added as a dev/test dependency so the vulnerability scan can be run (and wired into CI) going forward.

[stuartjohnpage]

@stuartjohnpage looks like you and I were working on the same thing today (#1152).

😹 Yes it does! I see you went for a bump to 3.0 rather than 3.1, and forcing the issue rather than the or. Both of those seem reasonable, with the caveat that forcing it means users will probably have to bump. I like the mix_audit addition!

I'm happy to go whichever way @akoutmos wants

[daveshah]

I'm happy to go whichever way
💯 agreed. And I do like your approach more - definitely more forgiving. I left mix_audit in there in hopes of maybe eventually getting that into CI. Definitely something we use 👍🏽

Happy with whatever the outcome - just looking forward to removing a override: true

[akoutmos]

Hey there and thanks for the PR! I'm going to close it in favor of #1153 as there is version 2.4 that also contains the security fix. With regards to mix_audit, I have another working branch at the moment with a big CI overhaul going on. I'll be sure to incorporate it in that PR.