With this feature is possible to remove previously manually added arguments like
mockbuild --disablerepo/--enablerepo, local --with/--without, ...
But I think when we already have them and some users possibly use them, removing could cause little confusion. It means removing them from help (functionality would be the same). Argparse help generator would not show them.

'update' command mentioned in the request will be treated in the fedpkg, because it is not part of rpkg common library.

I found "--" string separates regular arguments and extra arguments unnecessary. Is it OK? Or does it have a special function or is it a convention?

Personally I would expect the usage would be to always separate put the extra arguments at the end and separate them by --. That should prevent conflicts and I think -- is a relatively common way to indicate parsing arguments should stop.

For example fedpkg mockbuild -N --enable-network -- --with-ssl --without-python2. Anything before -- will go to fedpkg, anything after that will be given to mock directly.

I was considering it. But I didn't find the way how to do this via argparse library.
It is probably possible. But this approach would require lot of manual parsing because argparse will not even give me even a ordering of arguments.

I think it should be doable with argparse.REMAINDER. I'm not sure it always requires the -- in there, but it should support it.

I had a similar problem in compose-partial-copy, and in the end the solution is very similar to what is in this PR. I must have misremembered it.

https://pagure.io/compose-utils/blob/master/f/bin/compose-partial-copy

Right now it's possible to use the -- to avoid conflicts, but it's not required, right? If so, I guess it should be fine.

Despite I didn't find inspiration in compose-partial-copy, I found argparse.REMAINDER good tip for implementation. Thanks. It is significantly simpler than the original solution.
Current code lacks tests, I am gonna add some.
A lot of code changes in the PR modifies ordering of argument processing in methods regarding rpmbuild operations, hopefully with no functional consequences. The intension was better readability because methods do almost the same work and therefore they should look similar.

That is really very nice. I like it.

Unittests and minor corrections were just posted.