Save tx at transaction submit eventHandler for nightfall-client

[LijuJoseJJ]

What does this implement/fix? Explain your changes.

Changes in this PR includes

1. implement transactionSubmittedEventHandler for nightfall-client
2. save transaction in transactionSubmittedEventHandler if any of commitments and nullifiers are store in db for nightfall-client.
3. update blockProposedEventHandler of nightfall-client to delete duplicate transactions and their commitments from db, if the transaction not in L2 i.e deleted commitments are not nullified on chain yet.

Does this close any currently open issues?

This PR fixes #1335

What commands can I run to test the change?

Any other comments?

This PR also implements github workflow with test filetest/client-resync.test.mjs, where user created two transfers transaction using same set of commitments, while proposer setMakeBlock was off. Note: second transfer is with higher fee.
then proposer starts making block pick second tx and make a successful block.
[to test client re-sync feature] we are restarts client and all unsaved transaction are saved at transactionSubmitEventHandler
and at blockProposedEventHandler second tx updates and first tx deleted with change commitment it created.

explanation on test/client-resync.test.mjs

steps are.

1. do two deposit one by one each deposit test wait for TransactionSubmitted event and expect respective transaction hash and saved in client's db.
2. create first transfer transaction, we also make sure it got stored in client database by waiting for TransactionSubmitted and after that querying client transaction collection via api.
3. create second transfer transaction but this time we do not wait for TransactionSubmitted event also do not do makeBlock', and restart client immediatelyawait restartClient(nf3User);after client re-sync complete, check both transfer transactions in client db (this done at test by calling APIGET: /transactions`).
4. after client re-sync and above check, start proposer make block await makeBlock();.
5. At last check user balance also check user(client) transaction collections
   ( only three transaction should be in db, and last one should be of higher fee)

[Westlad]

Do we need to include the Transaction events in the Client synchronisation routine now, otherwise it may not finish synchronisation with a consistent database?

[Westlad]

Please add a test for your client synchronisation code (like the optimist resync test)

[LijuJoseJJ]

Please add a test for your client synchronisation code (like the optimist resync test)

added

[Westlad]

Please explain how to test this code (including with a re-sync of the client).

[LijuJoseJJ]

Please explain how to test this code (including with a re-sync of the client).

Thanks @Westlad for pointing it out.
I have updated description with the explanation of test/client-resync.test.mjs. (under Any other comments?)