Context

This PR updates the HTTP response codes returned by Iroha when handling transactions, making them more consistent and expressive for different failure modes. Currently, the API:

• Returns 200 OK when a transaction is accepted, with no response body.
• Returns 400 Bad Request for a wide variety of issues.
• Returns 500 Internal Server Error when the queue is full.

Problem

This approach lacks granularity and makes it hard for clients to reliably interpret what went wrong, especially in automated systems. It also does not follow common REST conventions.

Fixes #5391

Solution

This PR introduces the following improvements:

• 202 Accepted when a transaction is successfully accepted into the pipeline (instead of 200).
• 400 Bad Request for cases like:
  • Transaction already in queue
  • Transaction already in blockchain
  • Transaction expired or has a future timestamp
  • Transaction exceeds user limits
  • Chain ID mismatch
• 401 Unauthorized when signature verification fails.
• 403 Forbidden when the transaction is signed by the genesis account.
• 503 Service Unavailable when the transaction queue is full.

Migration Guide (optional)

Breaking Change:

• Clients that expect 200 OK upon transaction acceptance will now receive 202 Accepted. This should be updated in client-side logic.
• Status code-based error handling in clients may need to be updated to handle new codes: 401, 403, 503.

Review notes (optional)

• The change centralizes HTTP status code logic in IntoResponse, primarily matching error types.
• Review the logic around AcceptTransactionFail and PushIntoQueue for accurate status mapping.

Checklist

• I've read CONTRIBUTING.md.
• [] All CI checks pass.
• The response codes are aligned with the issue proposal.
• The status codes follow conventional RESTful standards.
• (optional) I've written unit tests for the error mapping logic.
• [] All review comments have been resolved.