Align usage of expiry and refund_timestamp

[thomaseizinger]

We use the term expiry for the SWAP REQUEST message but most of the RFCs talk about a refund_timestamp.

This usage should be unified, potentially with a 3rd term if none of the two fit for all the purposes.

• RFC003 defines the parameter as expiry: https://github.com/comit-network/RFCs/blob/master/RFC-003-SWAP-Basic.md#hash-time-lock-contract-htlc
• RFC005 was updated to use refund_timestamp everywhere in this PR: https://github.com/comit-network/RFCs/blob/master/RFC-005-SWAP-Basic-Bitcoin.md#contract
• RFC007 refers to it as expiry and refund_timestamp in different contexts: https://github.com/comit-network/RFCs/blob/master/RFC-007-SWAP-Basic-Ether.md#contract
• RFC009 is the same: https://github.com/comit-network/RFCs/blob/master/RFC-009-SWAP-Basic-ERC20.md#contract

Suggestion:

• Use expiry everywhere as mentioned in @da-kami comment here: Update instructions on how to build Bitcoin HTLC #90 (review)
• Update the code in comit-rs for generating the offsets to also use the term expiry. Here for example: https://github.com/comit-network/comit-rs/blob/master/vendor/blockchain_contracts/src/bin/calculate_offsets/ethereum/rfc003/templates/erc20/config.json#L10

[da-kami]

I feel it should be the other way round, as the original definition was expiry, as defined here: https://github.com/comit-network/RFCs/blob/master/RFC-003-SWAP-Basic.md

For me is both an advantage and a disadvantage to name very specific to the implementation.

[tcharding]

What about refund_expiry?. I approved the changes already but names can always be improved.

[thomaseizinger]

What about refund_expiry?. I approved the changes already but names can always be improved.

refund_expiry is a bit redundant. In the end, the HTLC expiring means it was not unlocked through the secret in time, and hence, the refund path can be triggered.