Gem updates for rmt3

[mssola]

Reacting to #1520 and #1535, I've done a general cleanup of gems for the RMT3 branch. I've separated things into commits, so for a better review go commit by commit instead of checking out the general diff. To highlight:

1. As suggested by the aforementioned depfu PRs, I've upgraded the gems suggested there and tested that nothing broke.
2. I've upgraded Puma from 7.x to 8.x and tested that nothing utterly broke. This has been previously discussed by @rtamalin and @digitaltom. I've also pinned down the Puma version so depfu doesn't automatically suggest major upgrades without us being sure about it.
3. I've pinned down mysql2 and nokogiri which are either crucial (mysql) or hard to upgrade (nokogiri) gems.
4. Upgraded the rest of gems to minor/patch level releases. This included an upgrade to rubocop, so I've added another commit which fixes issues brought up by the newly upgraded rubocop.

How to test

bundle exec rails and stuff. Everything should work as before.

Related PRs

Closes #1477
Closes #1520
Closes #1535

[mssola]

There's an error on feature tests when validating the resulting RPM, but I don't think it's related to this PR. @felixsch @rtamalin, is this a known issue?

[ngetahun]

There's an error on feature tests when validating the resulting RPM, but I don't think it's related to this PR. @felixsch @rtamalin, is this a known issue?

This is related to building transactional filesystem (like sl-micro and sle 16.1). Seems like one of the gems tries to change ownership in /etc

[rtamalin]

I think that feature test failure is a false positive; the regexp check being used to test for the restricted file system paths will erroneously match any path ending in /etc or /var/lib, not just the /etc or /var/lib paths.

To demonstrate, using a downloaded rmt-server-3.0.0 package from the 16.1 stream and checking for a path /rmt the old way yields the following:

30068d380cee:/ # rpm -qplv /var/cache/zypp/packages/SLE_BCI/x86_64/rmt-server-3.0.0-160099.1.10.x86_64.rpm | grep -E "^d.*/rmt$"
drwxr-xr-x    2 _rmt     nginx                       0 May 18 16:07 /etc/rmt
drwxr-xr-x    2 root     root                        0 May 18 16:07 /usr/lib64/rmt
drwxr-xr-x    2 root     root                        0 May 18 16:07 /usr/libexec/rmt
drwxr-xr-x    2 root     root                        0 May 18 16:07 /usr/share/rmt
drwxr-xr-x    2 root     root                        0 May 18 16:07 /usr/share/rmt/lib/rmt
drwxr-xr-x    2 _rmt     nginx                       0 May 18 16:07 /var/lib/rmt
30068d380cee:/ #

Adding a requirement to the regexp to match a whitespace before the target path yields the following:

30068d380cee:/ # rpm -qplv /var/cache/zypp/packages/SLE_BCI/x86_64/rmt-server-3.0.0-160099.1.10.x86_64.rpm | grep -e "^d.*[[:space:]]/rmt$"
30068d380cee:/ #

We also aren't using any extended regexp features, so we don't need the -E. ;-)

A change like the following should fix it:

diff --git a/ci/rmt-validate-packaging b/ci/rmt-validate-packaging
index 6efcdb2e..db9f9524 100755
--- a/ci/rmt-validate-packaging
+++ b/ci/rmt-validate-packaging
@@ -46,7 +46,7 @@ while IFS= read -r RPM; do

   # Check for forbidden directory ownership
   for dir_pattern in "${FORBIDDEN_DIRS[@]}"; do
-    if rpm -qplv "$RPM" 2>/dev/null | grep -E "^d.*${dir_pattern}"; then
+    if rpm -qplv "$RPM" 2>/dev/null | grep -e "^d.*[[:space:]]${dir_pattern}"; then
       echo "  ✗ ERROR: Package claims ownership of ${dir_pattern}"
       echo "    Top-level directories should be owned by filesystem package"
       ((ERRORS++))

[rtamalin]

I've proposed #1543 with the suggested CI fix.

[rtamalin]

#1543 has resolved the feature test RPM validation issue.

[rtamalin]

Looks good