disable downloading filelists by default

[lukewarmtemp]

Fixes coreos/fedora-coreos-tracker#1643

Disable filelists from being downloaded by default for Fedora 40. Adds
the DNF_CONTEXT_SETUP_SACK_FLAG_SKIP_FILELISTS where applicable,
which prevents the filelists from being downloaded.

For the changes in rpmostree_context_prepare(), disabling filelists is
conditional on whether a filepath was specified for rpm-ostree install
(ie. rpm-ostree install /usr/bin/htop).

For the changes in refresh_md_transaction_execute(), rpm-ostree refresh-md will not download filelists if they were not previously
downloaded. If they were previously downloaded, the filelists will be
updated.

Since there are many functions affected by this change, the option to
return to the previous filelist behaviour is also implemented. This is
done by adding:

[Service]
Environment="DOWNLOAD_FILELISTS=true"

in a newly created conf file under /etc/systemd/system/rpm-ostreed.service.d
For example: /etc/systemd/system/rpm-ostreed.service.d/filelists.conf

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[cgwalters]

I don't object to this at all, but I am uncertain about the bigger picture here versus aligning more with the dnf codebase more directly - e.g. dnf5 porting, or trying to do an even bigger hammer like forking off dnf as a binary...

[cgwalters]

I forgot to really be clear: Thanks so much for working on this! It is an important and notable change. And dropping filelists is a giant optimization for those who don't need them for sure, and having parity would be good.

I'm basically just saying though this will not be the last thing of this form where we have some nontrivial divergence from dnf and it is worth taking the opportunity to weigh changes like this versus larger structural changes to align more.

[jmarrero]

I am a bit confused as in the past porting rpm-ostree to dnf5 we did not see as a priority and I am not sure how forking the dnf binary vs dnf forking us on ostree systems would work, sounds like the could end up more tied up?

I guess, my question is, should we create a concrete plan before continuing to extend/modify rpm-ostree and basically just deal with bug fixes and put a hold on any other feature request while we trace what rpm-ostree in the ostree native container stable world looks like?

[travier]

I'm definitely +1 for doing this change. This will impact both server side and client side composes so everyone would benefit from it.

[cgwalters]

I am a bit confused as in the past porting rpm-ostree to dnf5 #2139 (comment)

You're right, I shouldn't have mentioned that particularly given the delays in dnf5.

[dustymabe]

Since F40 is quickly approaching can we try to finish this off?

[jmarrero]

this looks mostly lgtm, @lukewarmtemp can you squash the commits?

[jmarrero]

@lukewarmtemp mind rebasing?

[jmarrero]

lgtm