transaction generated for stake unlock

[darcys22]

Addressing #1351

So I've modified the unlock transaction to include a transaction sent to the users own address.

Attempting to resolve the issue using the second option:

Require that unlock txes have an output, and thus also a fee. Thus an unlock would now have 1-output back into the originating wallet, which would make the wallet see it.

However I am also of the opinion that the 3rd option of adding a burned amount to each stake unlock is a good idea.

Could I get some feedback on if this is the right path to be taking to generate an output for the unlock stake transaction?

[jagerman]

A couple of additions that would be useful here:

• a constant unlock burned fee added to cryptonote_config.h that gets added to the TX here, beginning if height indicates HF17+, if that constant is set to some amount > 0. For now we can probably just set it to some small amount (say 0.5 LOKI).
• enforcement of an output + required burn amount when processing an unlock tx. If the tx has no output, or has a burn amount too low, we should ignore the unlock details in the tx. (Again, this should only kick in starting at the first HF17 block).

[darcys22]

Have updated with the comments, few notes:

1. Added the UNSTAKE_BURN_FIXED constant to oxen_economy.h and created a new section to store staking fees constants. I saw a note on the get_staking_requirement() function in service_node_rules.cpp that it should be moved to oxen_economy also. It currently has a lot of tests for fork versions which might be due for removal in the next hard fork which would simplify it and make it easier to move here also
2. I've added the burn amount to the tx_params but unsure if this is the only step (Does an amount also need to be added to the amount field to account for this burn fee?
3. To check that the burn was included there is already a function in blockchain.cpp Blockchain::check_fee() does this handle the check or will an additional check be needed?

[jagerman]

I think we should hold off on merging this PR until post-HF. It really is something that goes along with oxen-io/oxen-improvement-proposals#27 which is slated for the next PR.