try to reset kernel crashkernel when kexec-tools updates the default crashkernel value
    
    Resolves: bz1895258
    Upstream: Fedora
    Conflict: None
    
    commit 0adb0f4a8c4c69ba54171f0113a4fbfc1729900f
    Author: Coiby Xu <coxu@redhat.com>
    Date:   Wed Dec 1 15:33:13 2021 +0800
    
        try to reset kernel crashkernel when kexec-tools updates the default crashkernel value
    
        kexec-tools could update the default crashkernel value.
        When auto_reset_crashkernel=yes, reset kernel to new crashkernel
        value in the following two cases,
         - crashkernel=auto is found in the kernel cmdline
         - the kernel crashkernel was previously set by kexec-tools i.e.
           the kernel is using old default crashkernel value
    
        To tell if the user is using a custom value for the kernel crashkernel
        or not, we assume the user would never use the default crashkernel value
        as custom value. When kexec-tools gets updated,
         1. save the default crashkernel value of the older package to
            /tmp/crashkernel (for POWER system, /tmp/crashkernel_fadump is saved
            as well).
         2. If auto_reset_crashkernel=yes, iterate all installed kernels.
            For each kernel, compare its crashkernel value with the old
            default crashkernel and reset it if yes
    
        The implementation makes use of two RPM scriptlets [2],
         - %pre is run before a package is installed so we can use it to save
           old default crashkernel value
         - %post is run after a package installed so we can use it to try to reset
           kernel crashkernel
    
        There are several problems when running kdumpctl in the RPM scripts
        for CoreOS/Atomic/Silverblue, for example, the lock can't be acquired by
        kdumpctl, "rpm-ostree kargs" can't be run and etc.. So don't enable this
        feature for CoreOS/Atomic/Silverblue.
    
        Note latest shellcheck (0.8.0) gives false positives about the
        associative array as of this commit. And Fedora's shellcheck is 0.7.2
        and can't even correctly parse the shell code because of the associative
        array.
    
        [1] https://github.com/koalaman/shellcheck/issues/2399
        [2] https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/
    
        Reviewed-by: Pingfan Liu <piliu@redhat.com>
        Reviewed-by: Philipp Rudo <prudo@redhat.com>
        Signed-off-by: Coiby Xu <coxu@redhat.com>
    
    Signed-off-by: Coiby Xu <coxu@redhat.com>