setup reclaim order

[kaze-cow]

Description

Adds the ReclaimOrder instruction. Also add some more capabilities to the test helpers.

Changes

The ReclaimOrder instruction is fairly simple: anyone can call this instruction once an order has expired to close the account and return the rent to the original order creator.

Besides the addition of the instruction itself, I found it would be very helpful if the unit tests could do more to validate the behavior of the function. So I added a new account initialization fixture, fake_account_with_data, which allows for creating an account that contains data that can subsequently be used to validate more conditions with particular input order PDAs. Unfortunately, due to the unusual dynamic memory layout of the RuntimeAccount type which puts the account data contiguously after the actual data is set, .

Additionally, Clock::get() always returns an error outside of a solana target_os context, so I replaced calls to this with a helper function get_timestamp that is stubbed to a static value (arbitrarily chosen to be 2026/01/01) for unit tests.

Finally, while writing the unit tests, I noticed its not ergonomic to create new order data because Default trait was not in use. So I added it using #[derive] macro. In the future we may want to refactor more of the tests to remove helpers like sample_intent which basically just give you a plain intent. The default pattern is just a lot more ergonomic and standardized.

With these optimizations, testing a function which has an input order PDA turned out to be relatively ergonomic in unit tests:

        let order_data = OrderAccount {
            created_by: Address::new_unique(),
            ..Default::default()
        };

        let order_pda = fake_account_with_data(Address::new_unique(), &EncodedOrderAccount::from(order_data)[..]);

How to test

Check CI. Observe the changes and consider if the general direction. Evaluate if the usage of additional unsafe code is warranted for what it accomplishes.

[linear-code]

SC-150 Close order account

Notion task

Review in Linear

[fedgiac]

I don't like this approach: it's a landmine for anyone who wants to use the settlement program outside the solana environment. The implicit assumption here is that this is only used for tests, and even then, we'd be testing with code that does something different from what we want to test for. What if unix_timestamp is in a different format, or if this has some meaningful side effect that we wouldn't know (like, increasing the number of CPIs and changing the logs)?
I see that the syscall invocation when os ≠ solana returns UnsupportedSysvar.
Maybe this unfortunately a good reason to actually end up using integration tests only. 😢

[fedgiac]

Mostly minor comments.
The only notable points are:

• I think there's a security issue because we don't validate the PDA before clearing it. Should be reasonably easy to address.
• I still don't like the complexity introduced to handle time in unit tests. I think it's fine to just do the one relevant test as an integration test. (Same if there were more.)
• I added a suggestion on how to (imho) improve the unsafe block.

[fedgiac]

Nit: it would be nicer to use the client's CreateOrder instead so you don't need to encode the order data manually. But then you wouldn't have the order PDA.

[kaze-cow]

doesn't seem clear cut atm, so leaving as is for the moment.