Clean-up retryable error codes

Current Fineract behaviour:

• optimistic locking exception: 423 SC_LOCKED
  the request was retried inside Fineract (configuration times) but was not successful

• • status: FAILED

• • when: more than one thread is trying to modify the same entity concurrently

• • caller: should retry with a NEW idempotency key

• • ams connector: implemented retry configuration times

• • issue: not ideal as 423 is a WebDav code

• • suggested: change to return code to 409 SC_CONFLICT

• pessimistic locking: 409 SC_CONFLICT
  the request was retried inside Fineract (different configuration times) but was not successful

• • status: not registered currently, should be FAILED

• • when: the COB process is currently running and we try to modify the entity
    only implemented on Loan so we will not have it on SavingsAccount

• • caller: should retry with a NEW idempotency key

• • ams connector: no retry, currently returns null

• • issue: same code as process in progress, must be different - already on prod, so finer act community should allow the change

• • suggested: fix audit log and keep return code 409 SC_CONFLICT

• process in progress: 409 SC_CONFLICT
  the request was already started by a different thread

• • status: IN PROGRESS

• • when: the process with same idempotency key was already started by a different thread
    specially for jobs (async requests), or for other processes if more than one instance can send the same request simultaneously (probably can not happen)

• • caller: should retry with the SAME idempotency key

• • ams connector: no retry, currently returns null because we do not have async requests, so another instance should return the correct response (success or failed)

• • issue: same code as pessimistic locking, must be different - already on prod, so finer act community should allow the change

• • suggested: change return code to 425 Too Early (RFC 8470), return null is probably ok

• deadlock: 500 (not handled so maybe different)
  deadlock is automatically retried but takes significant time so better to avoid

• • status: FAILED

• • when: example: two batches perform operation on the same entities but in different order

• • caller: should retry with a NEW idempotency key

• • ams connector: not handled

• • issue: implement or better to change the logic
    one of the deadlock types we already fixed in the ams connector:
    batch1: account1 operation, account2 operation; batch2: account2 operation, account1 operation
    was changed to
    batch1: account1 operation, account2 operation; batch2: account1 operation, account2 operation
    we also encountered deadlock on Savings transactions which is not handled yet

• • suggested: change Savings Transaction handling (core change) and handle deadlock exception
    change return code to 409 SC_CONFLICT