feat:added spotless and checkstyle configuration and added to maven b…

[akafredperry]

- What I did
This PR introduces the spotless and checkstyle plugins to the maven lifecyle. To ensure that all the code conforms a single formatting convention (spotless) and established coding style practices (checkstyle).

In order to pass, the code base has been adjusted.

In the intention here is to standardize all the code in a single commit and make future PRs easier to diff.

- How I did it
Added checkstyle and spotless maven plugins
Added java spotless rules
Added java checkstyle
Fixed checkstyle failures (lots of IF without braces, some deep block nesting)
Fixed spotless failures

- How to verify it
Run the tests

closes #343

- Description for the changelog
enforce a single java format and style convention

[akafredperry]

will be addressed by #345

In general, the problem is that encryption uses a fixed, static IV (EMPTY_IV). For secure use of block ciphers in modes like CBC, GCM, or CTR/SIC, each encryption operation under the same key must use a fresh, unpredictable IV/nonce. The standard pattern is: (1) generate a random IV with SecureRandom, (2) initialize the cipher with that IV, (3) include the IV alongside the ciphertext so decryption can reconstruct it (e.g., prefix the IV to the ciphertext or return/provide it separately).

The best focused fix here, without changing external functionality more than necessary, is:

• Stop using EMPTY_IV for encryption.
• Generate a random 16‑byte IV for each call to aesEncryptToBase64.
• Initialize the cipher with that random IV.
• Return the IV together with the ciphertext in a way that aesDecryptFromBase64 can consume without changing its signature. The simplest is to prefix the raw IV bytes to the ciphertext bytes and then base64-encode the combined array.
• Update aesDecryptFromBase64(String cipherTextBase64, String keyBase64) so that, when ivNonce is not provided, it expects this “IV + ciphertext” format: it decodes from base64, splits the first 16 bytes as IV and the rest as ciphertext, and then decrypts using the extracted IV. This preserves backward compatibility of the method signature while making encryption secure.
• Keep the overload aesDecryptFromBase64(String cipherTextBase64, String keyBase64, String ivNonce) for cases where the IV is transmitted separately, but discourage/default away from the EMPTY_IV path.

Concretely, within EncryptionUtil.java:

1. Add a SecureRandom-based IV generation in aesEncryptToBase64, using a 16‑byte IV (AES block size): e.g., SecureRandom random = new SecureRandom(); byte[] ivBytes = new byte[16]; random.nextBytes(ivBytes); IvParameterSpec iv = new IvParameterSpec(ivBytes);.
2. Change cipher.init(Cipher.ENCRYPT_MODE, key, EMPTY_IV); to use the newly generated IV.
3. Change the encrypted output to prefix the IV bytes: allocate a new byte array of length ivBytes.length + encrypted.length, copy the IV first, ciphertext after, then base64-encode that combined array.
4. In aesDecryptFromBase64(String cipherTextBase64, String keyBase64, String ivNonce), avoid defaulting to EMPTY_IV except where strictly necessary. For the 2‑argument overload (no explicit IV), implement the “decode, split IV + ciphertext, then decrypt” logic rather than delegating with ivNonce = null.
5. No new external dependencies are required; java.security.SecureRandom is already imported via java.security.*;.

In general, the problem should be fixed by never using a fixed, static IV for encryption. Instead, generate a fresh, unpredictable IV (or nonce) per encryption using SecureRandom, and communicate that IV alongside the ciphertext so that decryption can reconstruct the cipher state. For decryption, you must use the IV that was actually used during encryption; only the encrypt side needs randomness, but both sides must agree on the IV value.

For this specific code, the minimal change while preserving existing functionality shape is:

1. Stop using EMPTY_IV for encryption. In aesEncryptToBase64, generate a random 16‑byte IV using SecureRandom, initialize the cipher with that IV, and then return both the IV and ciphertext to the caller. Since we must not change the method signature, the most backwards‑compatible approach within this snippet is to encode the IV together with the ciphertext in the returned Base64 string. A common pattern is to prepend the IV bytes to the ciphertext and Base64‑encode the concatenation.
2. Update aesDecryptFromBase64 so that, when ivNonce is null (the current path that uses EMPTY_IV), it instead parses the returned Base64 string by splitting it into IV and ciphertext: decode Base64, take the first 16 bytes as the IV, and the remaining bytes as ciphertext. When ivNonce is non‑null, keep the current behavior of using _ivFromBase64(ivNonce) so that explicit IVs (if any) still work.
3. Remove usage of EMPTY_IV for encryption and, ideally, for decryption. If you still need a default for legacy data that truly used the all‑zero IV, you could keep a special case, but the safer default is to expect IV to be present in the encoded value.

This fix requires:

• Using SecureRandom from java.security (already imported via import java.security.*;).
• Some byte array concatenation logic inside aesEncryptToBase64 and corresponding splitting logic inside aesDecryptFromBase64.
• Keeping the existing method signatures unchanged so external callers still compile, while changing the internal encoding of the returned/consumed Base64 values.

---