Remove leniency check for /etc/(default|sysconfig)/elasticsearch

[jasontedor]

In #26057 we enabled set -e on the scripts. This means we exit if there's an error. For the Debian and RPM integration tests, we extract the contents of the package but do not install Elasticsearch. In the elasticsearch-env scripts for the Debian and RPM packages, we try to source /etc/(default|sysconfig)/elasticsearch. If we extract the contents but do not install the package, then there is no guarantee that these files exist and thus sourcing would fail. Since we enabled set -e, this means the scripts will fail, and the Debian and RPM integration tests will fail. To workaround this, we added a check for the existence of these files thus adding leniency to elasticsearch-env.

This issue proposes reverting adding this leniency. Instead, we should not be checking the Debian and RPM packages via these means, we should rely on real integration tests where we actually install from the packages and try to start Elasticsearch. We already have this: the packaging tests.

Therefore, the end game to removing the leniency check is simply removing the integration tests from the Debian and RPM package distributions, i.e., distribution/deb/build.gradle and distribution/rpm/build.gradle.

[nik9000]

I'm fine with removing these tests because we have the packing tests running consistently. I'd be fine with keeping them if we didn't have to add funky leniency to the distribution, but it feels like they aren't particularly "real" and since we already have "real" tests we should just use those.

[rjernst]

Sounds good to me. I will see if I can add a basic test to these projects so we know the built file isn't totally bogus (which is what the integTest was doing before). This could also help cleanup the gradle integ test setup, as supporting rpm/deb/tar complicates the setup a bit.

[jasontedor]

The JDK 9 builds are failing on the integration tests against the Debian and RPM packages because the packaging sets GC logging to these packages to /var/log/elasticsearch but there is no guarantee that when a cluster is spun up from this packaging (via bin/elasticsearch) (without being installed via rpm or apt-get and without being started as as service) that these directories exist or are even readable.