refactor init and setns process

[lifubang]

Because the initProcess and setnsProcess have many same fields, and they are all in a big file process_linux.go, so let's do some refactor to this file:

1. Introduce a common parent struct containerProcess, let both initProcess and setnsProcess are inherited from it;

2. Move initProcess and setnsProcess definition and implementation out of process_linux.go, let them in their own seperate files: init_process_linux.go and setns_process_linux.go, it will make more clear when reading and changing the code.
   EDIT: the second refactor could be refactored after the release-1.1 is EOL.

This refactor doesn't change any logic, and it's the first step of #4309 . After this refactor, both initProcess and setnsProcess can be treated as containerProcess, we can only need to write some logic for containerProcess, and then could be used for both initProcess and setnsProcess.

[kolyshkin]

Please add this PR description to the commit itself.

[kolyshkin]

I'd like to merge #4283 before this one because otherwise we can't do a revert.

Or maybe you can make a smaller refactor, without splitting process_linux into two files.

[kolyshkin]

Or maybe you can make a smaller refactor, without splitting process_linux into two files.

In fact, that would be better because when a lot of functions are moved from a file to a file, it makes it much harder to dig in git history.

[lifubang]

I'd like to merge #4283 before this one because otherwise we can't do a revert.

Yes, too many things need to consider.

Or maybe you can make a smaller refactor, without splitting process_linux into two files.

Yes, there is another problem, if we split this file, any changes about this file can't be backported to release-1.1 in the future.

[kolyshkin]

So, I was hoping that unifying this can help to deduplicate some methods: pid, externalDescriptors, forwardChildLogs, terminate, startTime, signal etc., if those are to be made methods of containerProcess.

[kolyshkin]

This looks better!

Yet perhaps it makes sense to merge it after the 1.2.0 release, as we're already at rc2 now. WDYT?

[lifubang]

Yet perhaps it makes sense to merge it after the 1.2.0 release, as we're already at rc2 now. WDYT?

I have no strong idea. I think this is a code refactor to let the code become more readable and reasonable, it doesn't change any logic.