Development Service

[amdfxlucas]

(Remote) Development Service

The DevelopmentService prepares a node for Remote Development with VSCode.
It installs the VSCode Remote Server on the Node during the docker image build, which allows to ssh into the running container later i.e. to debug software.
As of now the primary anticipated use of the seed-emulator has been the deployment of fully developed applications into an emulated szenario i.e. to observe its behaviour.
With the DevService this paradigm can be adapted to meet the need of developing i.e. P2P software to maturity in a distributed environment or giving assignments that involve programming tasks.

The DevService allows for each individual node that it is installed on, to specify one or more Git repositories that shall be checked out (along with the desired filesystem path and branch) as well as the VSCode Extensions required for the projects software stack (i.e. golang.Go for the SCION-proto implementation which is written in Go)
The DevService takes care to install the entirety of build and analysis tools that are needed for a given programming language at docker image build time (for Go this being i.e. the compiler, language server gopls, debugger delve) so that no annoying time delay arises once the emulator is running and you want to attach to a container.
Any specified Git repositories are checked out on its own separate docker volume, for the changes to persist between runs of the simulator in case one forgets to push.

Concerns:

• software development requires a 'real internet' connection of the container be it to git push/pull or fetch project dependencies for a build (i.e. go get, cargo build etc. ) This is achieved by promoting the nodes default gateway ( router node ) in the simulation into a 'RealWorldRouter' (which has access to the 000_svc service network)
  Use of a separate service network inhibits 'short-circuiting' the simulated network topology (i.e. any crosstalk past the intended network topo among nodes)

• I have to look into the VSCode CLI again !! Time delays when first attaching to a container ought to be kept small, and thus as much as possible should be done at image build time

[kevin-w-du]

Typically, when we add a new service, there is no need to change the core. But this PR changed many core files. It will be better if you can explain the reason behind that. Moreover, there are failed tests.

[amdfxlucas]

You are right. The DevService has 'special needs'. That is it requires 'RealWorld' Access to the outside Internet (for git push/pull and download of any dependencies ). Currently to support this, the user had to mind this requirement herself (and manually install 'RealWorldRouters' in the topology on every local-net with a node that requires RW-Connectivity )
Now what this PR does (in the changed core files) is to allow services to express their RWA requirements on their node's network so it is setup automatically and the user needn't cater for it manually anymore.
Routers will simply be grafted or promoted into RWRouters once the need is detected during configuration.
(this is only possible because joining the service network 000_svc doesn't change the actual simulation topology which is already configured once the Service Layers are processed by the emulator )
In order to facilitate this kind of promotion the notion of RouterExtensions is introduced (currently SCION & RealWorld) that can be installed on a router to add the required additional functionality.
This design is chosen over the alternatives i.e. Mixins that mess with the dynamic object type, because its compatible with pickle serialization/deserialization.

Moreover the restriction that Services can only be installed on hnodes is removed, because we'd also like to install DevServices on border routers to develop and debug new SCION features which might require 'hacking' the routers (i.e. new Extension Headers etc.).