Implement the specfile preprocessing without RPM parsing of specfile

[praiskup]

Parsing specfiles might be problematic, as specfiles are distribution specific.

On Fedora 41, e.g., it is impossible to parse some of the old spec
files, because:

error: %patchN is obsolete, use %patch N (or %patch -P N): %patch1 -p1 -b .loneZeroWarning

On older systems, it is impossible to parse new specfiles, because, e.g.:

SpecParseFailure: Couldn’t parse spec file jello.spec:
error: line 18: Unknown tag: BuildSystem:            pyproject

The rmpautospec should avoid the specfile-parsing-by-RPM business,
somehow. The tooling is a terribly low-level. Consider a simple
task like:

Generating a source archive from dist-git checkout

This would be as simple as having a git checkout, and archiving
git ls-files HEAD + lookaside files (call /bin/dist-git-client, e.g.)
Then, with rpmautospec we have to git fetch --unshallow first
(we have to deal with its problems, somehow #210, but still good!).

Now, to process the specfile with rpmautospec, we are actually
parsing the specfile by RPM. This can not be done safely in general -> to
stay on the safe side, we have to switch into an appropriate Mock chroot,
and run rpmautospec there.

I'm not sure how the commit c7e1796 is related.
I'm aware there's error_on_unparseable_spec, but I'm not sure what's the
risk of setting it to False.

[praiskup]

JFTR, weakly related to my "disagreement" with the design of rpmautospec
plugin in Mock: rpm-software-management/mock#1253
If we require specfile parsing by RPM, we need to move the parsing into
a Mock chroot. But it then complicates new distro bootstrapping.
One has to a) build python first, and all the other deps for rpmautospec, then
b) build rpmautospec, and c) start building tools that depend on rpmautospec
(any that rely on %autorelease and %autochangelog).

[praiskup]

Weak relation to #175

[sgallagher]

This is one of the main reasons for moving rpmautospec into a mock plugin: there's no way to ever guarantee that the host system will have a version of RPM that can parse any possible RPM specfile; we can only require that the spec matches the target distribution.

[praiskup]

there's no way to ever guarantee that the host system will have a version of RPM that can parse any possible RPM specfile

But note the flaw though. Consider as simple task as getting a source tarball
from DistGit checkout.
The thing is that DistGit is meant to be distribution-agnostic, same as the
source storage (dist-git). And tools like fedpkg or centpkg should be as
well, without the need to do fedpkg srpm (because that is not a
distro-agnostic task). Without rpmautospec, you can create a source tarball
from DistGit safely. With rpmautospec you no longer can (this is an
unfortunate precedent in the RPM stack).

I am not aiming at 100% perfect parser solution here, at all! The point is to
make the buildsystem/forge distro-agnostic and safe, and the underlying
tooling too. For a buildsystem tooling it is absolutely critical to not parse
specfiles (in non-isolated places), because that's not a safe operation (note
%( ) and %{lua: }, these are Turing Complete).

If we plan to rewrite rpmautospec for #217, I think it is good idea to think
about this particular problem now, because it seems the only thing we need here
is Epoch and Version expansion. It's just a matter of telling people to not
use anything dangerous in Version: and Epoch: when rpmautospec is being
used.

[praiskup]

There's a small experiment with norpm in #319. The norpm parser is known to fail on a few spec files @ rawhide, but admittedly those spec files are pretty ugly (using %{lua: } and %( ) in either Epoch or Version).
If we considered norpm to be a valid opt-in, we can discuss what to do about those failures.