init: make label rewriting more flexible

[nfeske]

In the context of #5445, the limitations of init's current label-rewriting mechanism become apparent. Let's recap, when routing a session request, a route can be selected by using a label (or a label suffix or a label prefix) as key. In the target node (<parent/> or <child name="..."/>), it is possible to replace the label by another one. For example, the following routing rule matches a ROM session labeled "config". If taken, the session is directed to the config_fs_rom server and the label is rewritten to "managed/runtime". So the server will hand out this file as ROM module, which then appears as "config" at the client.

<route>
  ...
  <service name="ROM" label="config">
    <child name="config_fs_rom" label="managed/runtime"/> </service>
  ...
</route>

In hierarchic scenarios (e.g., nested instances of init), labels assume a form like "runtime -> system_shell -> terminal -> config". The client's intent (in this case, the client wants to obtain "config") is successively watermarked by the chain of commands involved in the session creation (the session traverses the system-shell init as well as the runtime init before reaching the server).

In short, the label encodes two things: the expression of the client's intent (like the name of a ROM module), and an unforgeable (by the client) representation of the client's identity as observed by the server. The former is the last part of the label whereas the latter are all the leading parts.

Init's label rewriting mechanism is a nice tool of abstraction, which allows for grouping clients to roles. However, as the label can only be rewritten as a whole, the rewriting rule needs to know both the client's identity and the client's intent. Should the client's intent vary (e.g., a client requesting a variety of ROM modules), a dedicated rewriting rule is needed for each case. When expressing a file-system root as intent - as discussed at #5445 - this becomes impractical.

Therefore, init's label rewriting mechanism should be extended by three additional attributes. The identity attribute replaces all parts of the label except for the last one. The resource attribute replaces the last part of the label. The prepend_resource prepends the last part of the label with a given prefix (think of chroot).