Resolve "[feature] add repay percentage to close loan"

Fixes #1643 (closed)

Improving endpoint calculates the necessary details to perform a full or partial loan repayment based on the percentage of the loan (in basis points) that the user wishes to repay.

The main changes I have implemented are as follows:

1. Replacing the amount field in the API request with repay_bps. Instead of specifying the direct amount to be repaid, users will now indicate the percentage of the loan they wish to repay, in basis points.

2. In the response, I have introduced four new fields: expected_amount_in, streaming_swap_blocks, streaming_swap_seconds, and total_repay_seconds. These fields have been documented in the OpenAPI-generated documentation.

3. Regarding the estimation implementation, I encountered a challenge. The exact amount necessary for repaying a specific percentage of the loan is not easily predictable due to the various fees deducted from the sent amount, in addition to the price slippage impact. It is crucial that the estimation slightly exceeds the targeted percentage to ensure the loan's collateral is unlocked after 100% repayment. If the estimation falls short, the collateral remains locked.

To resolve this issue, I implemented a simulation-based approach starting at a threshold represented by a small quantity in BPS. This threshold amount increases by 10BPS until the simulation indicates that the repayment amount is equal to or greater than the user's requested percentage. In addition to this incremental approach, there is a limit where the simulations will stop at 1500BPS. This is to prevent malicious requests to the server. Consequently, the server will not conduct more than 15 simulations per request.

My knowledge of THORChain's codebase is limited by now, so I am seeking guidance on whether there is a more optimal way to predict the exact amount a user needs to repay.

Furthermore, I would appreciate a second opinion on the algorithm's variables, which are: the initial threshold, the threshold increment per iteration, and the maximum supported threshold. Perhaps the cap of 1500BPS and the iteration increment of 10BPS may not be the most optimal settings for the current state of the network, and I am open to suggestions for improvement.

UPDATE

Also add fields: streaming_swap_blocks, streaming_swap_seconds, and total_open_loan_seconds in endpoint open/loan. These fields have been documented in the OpenAPI-generated documentation.