however since it's not documented how or why systemd-escape fails like this,
rather than rely on internal implementation details of why systemd-escape fails
here, we just accept our current implementation while testing that we are
consistent with behavior for this type of path. If systemd-escape(1) official
docs ever explain why this is considered invalid then we can try to deny this
too, but until then leaving it as is probably fine.
systemd/escape: fix issues with "" and "\t" handling
"" is treated as "/", however filepath.Clean("") gives "." which then gets
escaped and is incorrect.
"\t" needs the prefixing 0 in the \x escaping to match systemd-escape(1)
exactly, the easy way to have Go do this automatically is to use %x format spec
with a byte list.
Add many more unit tests here and stop importing the package with "." as it is
slightly confusing.
many: use more specific check for unit test mocking
Currently, if you try to use a snap with an app named "test", os.Args will also
end in ".test", making numerous places in the codebase think that it is being
run in a test environment and behave differently. In the case of the reported
bug, the code panics from `snap run` as it seems to the mountinfo code that we
are not mocking something that we should always be mocking in unit tests.
The bug could still hypothetically happen if someone made a symlink from
somewhere with "go-build" in the path (but not as part of the app name in the
snap) and a .test suffix on the executable, but this is sufficiently specific
that it is highly unlikely we would ever actually run into that problem "in the
wild".
