feat: converted init_systems plugin to v1

[jstucke]

No description provided.

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 92.72727% with 12 lines in your changes missing coverage. Please review.

Project coverage is 91.59%. Comparing base (947a5cb) to head (87e3661).
Report is 8 commits behind head on master.

Files with missing lines	Patch %	Lines
.../plugins/analysis/init_systems/code/init_system.py	88.88%	12 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1346      +/-   ##
==========================================
- Coverage   92.54%   91.59%   -0.95%     
==========================================
  Files         381      376       -5     
  Lines       24397    20999    -3398     
==========================================
- Hits        22577    19234    -3343     
+ Misses       1820     1765      -55     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[maringuu]

Contrary to my comment above, I'm not sure if we should simplify this plugin to do the following:

1. Detect init-systems by filename (As is done currently)
2. Display the whole file contents in the frontend

Currently, the schema does not seem too useful to me.
What do you think?

[maringuu]

Unneeded re.MULTILINE

[jstucke]

fixed

[maringuu]

I would prefer sth. like this:

class Schema(BaseModel):
    class SystemD:
        #: A list of all ExecStart lines
        exec_start: list[str]
        #: The Description of the unit
        description: str

    class Inittab:
        class Entry:
            id: str
            state: str
            action: str
            process: str
        entries: list[Entry]

    class Upstart:
        ...

    class SysVInit:
        ...

    systemd: Optional[SystemD]
    inittab: Optional[Inittab]
    sysvinit: Optional[SysVInit]
    upstart: Optional[Upstart]

I find it hard to argue for/against anything since I haven't had a use case for this plugin.
The only thing I can imagine is searching for units that execute a specific executable.
However, I think that the usefulness of a plugin increases with a more structured result.

[maringuu]

Also, isn't init_type != None equivalent to is_init?

[jstucke]

I would prefer sth. like this:

class Schema(BaseModel):
        ...

I find it hard to argue for/against anything since I haven't had a use case for this plugin. The only thing I can imagine is searching for units that execute a specific executable. However, I think that the usefulness of a plugin increases with a more structured result.

Hmm I don't think it makes a lot sense to have a result with the keys systemd, inittab, sysvinit and upstart and every value except one (at most) is None (and it gets even worse when we add more types like procd). Having the result as a list also doesn't make a lot of sense. How about inheritance? Can we have a "InitData" base class with more concrete inheritors with more fields? Does JSON schema support that?

Also, isn't init_type != None equivalent to is_init?

Yes, absolutely. This could only bring better readability in code/queries but is totally redundant . It's probably better to throw it out

[jstucke]

I changed it so that is uses multiple data classes with Union[]. This is equivalent to a "anyOf" relation in JSON schema. There seems to be no way to connect it directly to the type of init system, though.