fix: AtomicIntegerArray null element produces misleading error

[Jerryyy985]

Summary

ATOMIC_INTEGER_ARRAY reads elements via raw in.nextInt() and only catches NumberFormatException; a JSON null element escapes as IllegalStateException wrapped in a misleading adapter-not-null-safe JsonSyntaxException (with a wrong troubleshooting hint).

Fix

Mirror atomicLongArrayAdapter (from #3038): factory-based adapter reading elements through a Number TypeAdapter, throwing a clean JsonSyntaxException("null is not a valid AtomicIntegerArray element") on null. Registered symmetrically in GsonBuilder.

Verified: [1,null,3] now produces the same clean error as AtomicLongArray; normal/empty/top-level-null paths unaffected.

Fixes #3047

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[Marcono1234]

Thanks!

Instead of delegating to the TypeAdapter for Integer, an alternative would be to add a in.peek() == JsonToken.NULL check before calling in.nextInt(). That would most likely be more efficient because it avoids boxing.

---

wrapped in a misleading adapter-not-null-safe JsonSyntaxException (with a wrong troubleshooting hint)

The hint says though "a built-in adapter does not support JSON null values", so it might not be completely misleading. But any PR for improving the Troubleshooting Guide is welcome!

---

My main concern here is if this change is really needed. #3038 was definitely an issue because it fixed a NullPointerException, which would have had no detail information for the user.
But here for AtomicIntegerArray this is only about a slight error message improvement.

I suspect only few users actually deserialize AtomicIntegerArray, and even fewer would encounter this error. And the current exception message is probably still somewhat useful.

Additionally, this code pattern of directly calling a JsonReader method (nextInt(), nextBoolean(), ...) without explicit check for JSON null and custom error reporting first is pretty common in the Gson code base. Adjusting just one specific case seems a bit inconsistent; and trying to adjust all seems unnecessary.
Edit: Maybe I am wrong with this, and it only affects a few adapters which read arrays and objects; specifically TypeAdapters#ATOMIC_INTEGER_ARRAY (which you are changing in this PR), TypeAdapters$IntegerFieldsTypeAdapter, JavaTimeTypeAdapters. But still not completely sure if this is worth it.

(Note that I am not a direct member of this project; this is my personal opinion on this.)

[Marcono1234]

Would probably be good to include in.getPreviousPath() here in the exception messsage, see also #3096