Add wrapper for service manipulation

[dimitry-ishenko]

Description

Add consistent interface to enable/disable, start/stop and query systemd services. This PR tries to abstract package manipulation (not entirely unlike PR #320), remove some boiler-plate and have something that's easy to maintain in the future.

For example, srv_reload, srv_start, etc. functions check if they are running inside container, and if so, will silently ignore their command.

Implementation Details

The following functions were added:

srv_active  some.service
srv_disable some.service
srv_enable  some.service
srv_enabled some.service
srv_mask    some.service
srv_reload  some.service
srv_restart some.service
srv_start   some.service
srv_stop    some.service
srv_unmask  some.service

Testing Procedure

TBD

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have ensured that my changes do not introduce new warnings or errors
• No new external dependencies are included
• Changes have been tested and verified
• I have included necessary metadata in the code, including associative arrays

[Tearran]

Haven't had a chance to test it yet, But at glance it is great approach. no UX and is noint Can be used in a module without integrating the UX.
Perhaps instead of interface ,some other name, for general reusable functions. ie no UX No interface helpers

[dimitry-ishenko]

Perhaps instead of interface ,some other name, for general reusable functions. ie no UX No interface helpers

The reason I chose "interface" is that it's an API in a sense for service manipulation.

What about interface_service.sh -> service.sh?

[Tearran]

my point in interface is it would be for a group name for interface_helpers as this and pkg_ seem to fit as well, limited to one word so. Still any_name_will _do.sh If we can discuss naming conventions file and or function prefix_ #325 for this topic and change it later if we have to.