Baking: Register baker

[jens-concordium]

Task description

If the account is not already registered as a baker, it will be possible submit a "Register baker" transaction. Technically it's just the ConfigureBaker transaction, like all the other "baker transactions". When registering a baker all parameters of the ConfigureBaker transaction is required, even commission rates and metadataURL. As it is right now, the user will never be presented with the commission rates, and the metadataURL is only presented to the user in Scenario 2 below.

There are two scenarios for the register baker transaction:

1. The baker is registered with a pool open for delegation
2. The baker is registered with a pool closed for delegation

Both scenarios can be found in the box called Register baker flows in Figma.

Scenario 1 (closed pool):

• The flow can be started from the baker status page, if the account is not already registered as a baker.
• On the first page the user can input the baker stake, and they must decide whether they want to restake their rewards or not. There will be a minimum stake, which will be available from the wallet proxy. Besides that, the UI must handle situations where the user doesn't have enough funds, where the user is trying to stake more than what is allowed for a baker or if the user is trying to stake more than 95% of their public balance.
• On the second page the user must decide whether they want their baker to be open for delegation or not. (This scenario is the one with the open pool).
• On the third page the baker keys are generated. They must be exported before the user can continue. The user will be met by a notification saying, that these keys are important and they cannot be recreated. The keys will be saved somewhere, using the OS functionality to do so.
• On the fourth page the user can see a pre-submission overview of the transaction. If acceptable, the user can submit the transaction.
• On the fifth page the user can see the transaction ticket, now including the transaction hash. Pressing "Finish" will let the user know that after the transaction has finalized, the transaction will take effect from the next pay day, and that they should remember to restart their node with the baker keys.

After finishing the flow, the user will be taken to the baker status page.

Scenario 2 (open pool):

• For scenario 2 the only difference compared to scenario 1, is that the user has the option to input a metadata URL. This option is on the page after the one, where the user decides whether to open or close the pool for delegation. The metadata URL can be left empty, in which case we must submit an empty string in the transaction.
• In the overview with the transaction ticket, we should either show the supplied metadata URL, or if it was left empty we will just state "Empty" in the ticket.

[jens-concordium]

Note: After generating the baker credentials / baker keys, the baker ID should be added to the credentials. The baker ID can be retrieved with a query to the wallet-proxy.

[jens-concordium]

Note: The estimated transaction fee shown on the "amount page" during the register baker flows, will have to be shown as a range, because the potential metadata URL can vary in length, hence preventing us from estimating an exact fee before we know the actual length. It should be possible to get this info from the wallet-proxy.