[TASK] Add a `services.pre_register` call

[shekohex]

Overview

A simple call (similar to services.register) that does signal our interest in registering on this blueprint. It only emits an event PreRegistered { operator, blueprint_id } so that the shell could consume this event, download the gadget binary and execute it in the Registration Mode*.

Gadget Registration Mode

Normally, running the gadget will start the event watcher and watch for JobCalled events, that way it will execute jobs. However, running the gadget binary with REGISTRATION_MODE=on should instead do the actual registration process. In some sense, the shell manager will execute the gadget normally, but setting the REGISTRATION_MODE=on env to that process indicating that this gadget should run the Registration function instead of listing for jobs.

Why?

The mean reason behind this call is so that to automate the registration process; from the perspective of the operator; simply by calling services.pre_register() extrinsic it will emit the PreRegistered event that will be picked by the shell-manager to continue the process. This avoids going through SSH to the box or registering manually.

[drewstone]

I don't know if I think having a different mode is the route IMO. I see it being simpler if you just

1. Listen for pre-register events. If we see them, we download binary and execute registration function immediately. Store the result and continue listening for events.
2. Listen for register events. If we see them, we check if we have the binary and if not we download. If we do have it, we spawn the gadget.

Simple as that, no need for too much alt branching in the code.

[shekohex]

@drewstone

we download binary and execute registration function immediately.

How would the gadget binary know which function to execute? i.e The shell manager want to call the registration function on the binary, how would that work in your opinion? I may be missing something here.