[TECH DEBT] Automate tests for packaging and onedir with optional modules

[DaAwesomeP]

Description of the tech debt to be addressed, include links and screenshots

In the process of moving to onedir I have encountered countless issues that could easily be caught by testing release packages prior to releasing. Most notably in the first iteration of onedir the usage of curl broke (see #62949) and with relenv the ability to install any modules requiring bundled shared libraries has broken (see #64121 and #64288).

These could all be caught with a test that 1) installs a packaged version of Salt, 2) installs optional dependencies, and 3) tests salt states with those dependencies. At this point these don't even need to be thorough tests; they just need to test that applying a state using one of these modules does not result in a Python runtime error.

There are also some other errors that could similarly be found by running tests on actual packaged environments (such as #64118 and #64157), or in the case of modules with often-changing APIs those optional modules should also be tested (see #58920). However, given all of the changes with onedir I think testing optional modules in an installed package environment should be a first step.

Versions Report

N/A, see linked issues.

[ITJamie]

another one for the list
nacl on debian 11 segfaults #64342

testing really needs to be done with the optional modules across a suite of supported os's of the actual relenv build

I agree that most of these most of these could be quickly tested in a docker container (see the nacl issue above) and a quick salt-call -local to the modules in question. there would be no need to run the whole suite, just a basic set of tests. in some cases the salt-pip install of additional packages may fail