[SRU jammy:linux-*-6.2] Revert variable symbol length modversion patch

[Andrea Righi]

NOTE: this SRU doesn't have any patch, it explains a special action to
do if you are cranking a Jammy kernel that is derived from Lunar.

[Impact]

In order to support Rust in the kernel starting with Lunar we had to
apply the following UBUNTU SAUCE patch:

  27c4fe11712c ("UBUNTU: SAUCE: modpost: support arbitrary symbol length in modversion")

This patch can potentially introduce a user-space regression, because it
alters how the module names are stored in the modversion_info area.
Realistically it doesn't break anything, since this area is used only by
the kmod tools (and they've been verified to work fine also with this
change applied).

However, to be 100% that we don't introduce regressions it is safer to
simply revert this patch, considering that we don't provide kernel Rust
support in Jammy and without Rust this patch doesn't provide any
benefit.

[Fix]

In order to fix this we need to explicitly revert the patch in all the
Jammy kernels that are derived from any Lunar kernel.

To do so, after `cranky rebase`, run:

 git revert -s 27c4fe11712c

[ The sha1 should correspond to the proper patch to revert, otherwise
  make sure that the patch "UBUNTU: SAUCE: modpost: support arbitrary
  symbol length in modversion" is not applied, or it's already reverted ]

The comment for the revert should report something like this:
```

 Revert "UBUNTU: SAUCE: modpost: support arbitrary symbol length in modversion"

 This patch is required by Rust and it can potentially break user-space.
 It is safer to revert this in all the kernel backported to old releases.
```

[Regression potential]

This revert is not very critical, realistically even with the variable
modversions patch applied we won't regress any known tool, however we
don't to risk to introduce potential user-space ABI changes. Fixing this
requires a slightly different action, respect to our usual workflow, so
if some kernels are shipped with the variable modversion patch (for any
reason), we may experience regressions with kmod-related tools (e.g.,
scripts that are using modinfo, modprobe and similar or custom tools
that are parsing .ko sections directly).