fix: handle prepare response when number of fields in the prepare header does not match the actual number in the response

[sidorares]

ref: #2052

Update: main reason for the #2052 is not the medatdata_follows flag and/or missing parameters. The issue is caused by prepare header returning number of placeholders in the query ( 1 for select * from user order by ? ) but the actual number of parameters following the header is 0 - see #2052 (comment). Changing the scope of this PR to handle "ignored" parameters / columns

---

Context: we currently expect that prepare response has exactly num fields + num parameters ColumnnDefinition packets in the response. However ether of them could be skipped by the server even when num fields is > 0 and/or num parameters > 0.

See https://dev.mysql.com/doc/dev/mysql-server/latest/page_protocol_com_stmt_prepare.html

if num_params > 0 and CLIENT_OPTIONAL_RESULTSET_METADATA is not set or if medatdata_follows is RESULTSET_METADATA_FULL num_params packets will follow. Then a EOF_Packet will be transmitted, provided that CLIENT_DEPRECATE_EOF is not set.

• allow to handle exception from test example in fix: keepAliveInitialDelay not taking effect #2043
• I plan to gradually switch to a built in node test runner. Add a setup to run new tests in node v20 using built in runner
• add a unit test (initially failing)

Descoping:

• parse metadata_follows in COM_STMT_PREPARE_OK packet deserealisation
• expect possible EOF packet where we currently read ColumnDefinition based on OPTIONAL_RESULTSET_METADATA / DEPRECATE_EOF connection flags and metadata_follows COM_STMT_PREPARE_OK packet
• verify that empty parameters / fields array does not break rest of the "execute PS" logic. For example, we currently might fail .execute() call if expected and actual number of parameters do not match. In that case 2 options: store them separately ( reported number of parameters and array of deserialised parameter metadata ( could be empty ) OR fill array with default / unknown metadata.

[github-actions]

Coverage report

The coverage rate is 90.10981072099408%

The branch rate is 84.96134926212228%

100% of new lines are covered.

[sidorares]

I messed up something with cherry picking, recreating this in a new PR