Nayms - OnRe Offer/Redemption Program Spec

When calculating how many tokens the user should receive in the `calculate_buy_amount()` function, there is a potential for some small amount of precision to be lost when the sell token has more decimals than the buy token. This is important because the team has outlined their intent to use `USDC` (six decimals) in the protocol, while the `ONe` and `rONe` tokens both have nine decimals. There are two scenarios to be aware of that could cause problems: 1. The user requests to redeem an amount of `rONE` tokens with seven or more decimals. 2. The `USDC`:`ONe` ratio when calling the `take_offer_two()` function causes a normal redemption amount to lose some precision when redeeming a partial amount in `USDC`.

The protocol uses `offer_id` values as critical seed values for deriving Program Derived Addresses (PDAs) for both offer accounts and offer authorities. While the program specification implicitly assumes offer IDs are unique, there is no on-chain mechanism to enforce this uniqueness. Offer IDs can be reused after an offer is closed, which could lead to confusion in the event logs and also issues where previously opened (and then closed) PDA accounts are reopened again. An additional issue here would be if the `boss` account becomes compromised, the new malicious boss could create an offer specifying a particular token exchange rate and then front run a users attempt to fill that order to create a new order with the same `offer_id` now offering a significantly worse exchange rate to the user.