A few of the actors analyze the openssl configuration file,
and leapp-repository carries a bare-bones parser for it.
At least opensslenginescheck.py, in its quest for figuring out the effective values,
stops at the first appropriately-named block and takes the value from there.
Unfortunately, that's not how the real openssl parser treats the config file:
the blocks bearing the same name can repeat and the values in the repeated blocks override the values in prior ones.

What is the impact of this issue to you?

Customers that define engines usage in sections with duplicated names will not be warned about their usage of engines during 9to10 upgrades.

Please provide the package NVR for which the bug is seen: leapp-upgrade-el9toel10-0.22.0-1.el9

How reproducible is this bug?: reliably

Steps to reproduce

1. append a section to an otherwise default `/etc/pki/tls/openssl.cnf`
      that should get the config flagged for using engines,
      e.g., the following example from openssl-ibmca documentation:

[openssl_init]
engines = engine_section
[engine_section]
pkcs11 = pkcs11_section
[pkcs11_section]
engine_id = pkcs11
dynamic_path = /usr/lib/ssl/engines/libpkcs11.so
MODULE_PATH = opensc-pkcs11.so
init = 0

1. run leapp preupgrade

Expected results

opensslenginescheck.py flags the usage of engines usage and warns the user.

Actual results

opensslenginescheck.py does not flag the engines usage
(because it looks at the preceding sections and never even reaches the overridden blocks/values in its traversal).

While it's tempting to just do the merging at config reading time, at least one check cares about the unmerged configuration file representation.