Refactor SQL module to use PreparedStatement (#1611)

[ferCancholaCruz]

This PR refactors parts of the SQL module to use PreparedStatement instead of SQL string concatenation, in accordance with issue #1611.

✅ Refactored:

• SQLSpout.java: replaced string-based query building with PreparedStatement
• IndexerBolt.java: refactored dynamic insert with metadata into a clean, safe PreparedStatement

☑️ StatusUpdaterBolt.java already used PreparedStatement correctly and did not require changes.

The module compiles cleanly with mvn clean install -DskipTests and follows recommended SQL practices.

Closes #1611

[jnioche]

Thanks for contributing @ferCancholaCruz

Can you please reinstate the license headers and comments that your PR removed?
Also please run the formatting with
mvn git-code-format:format-code -Dgcf.globPattern="**/*" -Dskip.format.code=false
prior to committing. Most of the changes in your PR have nothing to do with what you are trying to achieve but are changes to the formatting that is established for the project,

Thanks!

[sigee]

To be honest, I do not really get why do you changed the single StringBuilder query to StringBuilder fieldsBuilder, StringBuilder placeholdersBuilder and StringBuilder updatesBuilder with the overcomplicated query building? One single for loop appends different parts to different StringBuilders. The original version was already a PreparedStatement. I can't see any additional value replacing it. Finally it is the same SQL query generated with more resource is used.
Am I missing something?

[rzo1]

The original intention of the issue was to replace direct String concat with parameter replacements and pre-build queries. The SQL strings could be prepared on init and just looked up (might open the was for a more sophisticated solution using a connection pool).

Side note: One would need to sanitize table names, too, because they cannot be set as ? In a prepared statement, so might be good to add a simple check.

[rzo1]

I agree with @sigee here. We shouldn't create a lot of StringBuilders here and instead use parameter replacement were needed. In addition, I would add a simple (regex) check for the table name to avoid anything unexpected.