Problem

When nested stored procedures raise multiple errors using RAISERROR, the JDBC driver only surfaces the first exception.
Although SQL Server sends all errors in the TDS stream, the driver stops parsing early and:

• SQLException.getNextException() returns null
• Only the first error is visible to applications
• Behavior diverges from SSMS and SQL Server semantics
  Example:
  -- P2 (inner procedure) raises error and returns
-- P1 (outer procedure) calls P2, then raises its own error
EXEC P1
  Expected: 2 exceptions
  Actual: only the inner exception is visible

Root Cause

The JDBC driver stops parsing the TDS stream early when it encounters a DONEINPROC token with the error flag set. This causes:

• Parsing to terminate before subsequent error tokens are read
• The driver to throw the first exception immediately
• Remaining errors to be left unread in the stream

Modifying the TDS parsing state machine to continue parsing was explored, but doing so breaks existing driver behavior, especially when mixed with SELECT result sets inside stored procedures.

Solution

Instead of modifying the core TDS parsing behavior, this PR introduces lazy exception chaining by overriding getNextException() in SQLServerException to resume TDS parsing via Statement.getMoreResults().

With this approach, the driver continues parsing the TDS stream only when the application explicitly requests the next exception. When invoked, getNextException() safely resumes parsing, reads the next error token already sent by SQL Server, throws it internally, and chains it to the original exception in the correct order.

This ensures that all errors from nested stored procedures, including 3-4 or more levels, are reliably surfaced, while preserving backward compatibility and existing driver behavior.

Testing

• testExceptionChaining – Validates exception chaining with 2 nested stored procedures
• testExceptionChainingWith4NestedProcs – Validates chaining across 4 nested stored procedures
• testExceptionChainingWithGetMoreResults – Verifies exception retrieval using a manual getMoreResults() loop
• testExceptionChainingWith3NestedProcs– Tests exception chaining via getNextException() with 3 nested stored procedures.
• testExceptionChainingWithDifferentErrorTypes – Verifies exception chaining across 3 nested stored procedures when each procedure throws a different SQL error type (division by zero and distinct RAISERRORs), ensuring chaining works beyond RAISERROR-only scenarios.
• testExceptionChainingWithClosedStatement – Verifies that getNextException() returns null when the statement is closed after an exception is thrown, instead of throwing a “statement is closed” error that would mask the original exception.

Part1: #2251

Fixes #2115