[minor] Handle Upgrade Retry with --next-channel Argument

[anilprajapatiibm]

This PR adds support for retrying MAS upgrades when the core has already been upgraded but applications are stuck on an older channel. It introduces a new --next-channel optional argument to the mas upgrade command that allows users to explicitly specify the target MAS channel.

Changes Made

1. New Argument (python/src/mas/cli/upgrade/argParser.py)
   --next-channel <channel> # Optional: Target MAS channel to upgrade to
2. Core Logic (python/src/mas/cli/upgrade/app.py)
   Added channel validation logic
   Implemented retry scenario detection
   Added app compatibility validation
   Enhanced masChannel parameter handling for ansible-devops
3. Test Coverage (python/test/upgrade/test_upgrade_channel.py)
   5 comprehensive test scenarios covering all use cases
   All tests passing ✅

Pseudo Logic

FUNCTION upgrade(args):
    1. Extract nextChannel from args.next_channel
    
    2. Get currentChannel from cluster (MAS core subscription)
    
    3. IF currentChannel exists:
        a. IF nextChannel is provided by user:
            i.   IF nextChannel == currentChannel:
                    → RETRY SCENARIO: Core already upgraded, apps need upgrade
                    → Display message: "Retrying upgrade to {nextChannel}"
            
            ii.  ELSE IF nextChannel == upgrade_path[currentChannel]:
                    → VALID UPGRADE: Normal upgrade path
                    → Proceed with upgrade
            
            iii. ELSE:
                    → INVALID PATH: User trying to skip versions
                    → FATAL ERROR: "No upgrade path from {currentChannel} to {nextChannel}"
        
        b. ELSE (no nextChannel provided):
            i.   IF currentChannel in upgrade_path:
                    → AUTO-DETERMINE: Use upgrade_path dictionary
                    → nextChannel = upgrade_path[currentChannel]
            
            ii.  ELSE:
                    → FATAL ERROR: "Already on latest release {currentChannel}"
        
        c. Validate app compatibility with nextChannel:
            FOR EACH installed app:
                IF app not compatible with nextChannel:
                    → FATAL ERROR: "App {appId} incompatible with {nextChannel}"
    
    4. Determine masChannel parameter for ansible-devops:
        a. IF nextChannel provided AND nextChannel == currentChannel:
            → RETRY: Find previousChannel from upgrade_path
            → masChannel = previousChannel (so ansible upgrades apps)
        
        b. ELSE IF nextChannel provided AND nextChannel != currentChannel:
            → REGULAR: masChannel = currentChannel (so ansible looks up next)
        
        c. ELSE:
            → AUTO: masChannel = "" (ansible auto-determines)
    
    5. Launch upgrade pipeline with masChannel parameter

Use Cases & Examples

Use Case 1: Normal Upgrade (No --next-channel)
Scenario: User wants to upgrade from 8.11.x to the next available version

mas upgrade --mas-instance-id inst1 --no-confirm --accept-license

What happens:

Current channel: 8.11.x
Auto-determined next channel: 9.0.x (from upgrade_path)
masChannel passed to ansible: "" (empty - auto-determine)
Result: ✅ Upgrades MAS core and apps from 8.11.x → 9.0.x

Use Case 2: Explicit Upgrade with --next-channel
Scenario: User wants to explicitly upgrade to 9.0.x

mas upgrade --mas-instance-id inst1 --next-channel 9.0.x --no-confirm --accept-license

What happens:

Current channel: 8.11.x
User-specified next channel: 9.0.x
Validation: ✅ 9.0.x == upgrade_path["8.11.x"] (valid path)
masChannel passed to ansible: "8.11.x" (so ansible looks up next)
Result: ✅ Upgrades MAS core and apps from 8.11.x → 9.0.x

Use Case 3: Retry Scenario (Core Already Upgraded) ⭐ NEW
Scenario: MAS core upgraded to 9.0.x but apps stuck on 8.11.x channel

mas upgrade --mas-instance-id inst1 --next-channel 9.0.x --no-confirm --accept-license

What happens:

Current channel: 9.0.x (core already upgraded)
User-specified next channel: 9.0.x (same as current)
Detection: ✅ Retry scenario detected (nextChannel == currentChannel)
masChannel passed to ansible: "8.11.x" (previous channel, so ansible upgrades apps)
Result: ✅ Re-runs upgrade to ensure apps catch up to 9.0.x
Why this works:

When masChannel = "8.11.x", ansible-devops looks up upgrade_path["8.11.x"] → "9.0.x"
This triggers app upgrades from 8.11.x → 9.0.x channels
Core stays on 9.0.x (already there), apps get upgraded

Use Case 4: Invalid Upgrade Path
Scenario: User tries to skip a version

mas upgrade --mas-instance-id inst1 --next-channel 9.1.x --no-confirm --accept-license

What happens:

Current channel: 8.11.x
User-specified next channel: 9.1.x
Validation: ❌ 9.1.x != upgrade_path["8.11.x"] (invalid - skips 9.0.x)
Result: ❌ FATAL ERROR: "No upgrade path available from 8.11.x to 9.1.x"

Use Case 5: App Compatibility Validation
Scenario: Manage app on incompatible channel

mas upgrade --mas-instance-id inst1 --next-channel 9.1.x --no-confirm --accept-license

What happens:

Current channel: 9.0.x
User-specified next channel: 9.1.x
Installed apps: Manage on 8.7.x
Validation: ❌ Manage 8.7.x not compatible with MAS 9.1.x
Result: ❌ FATAL ERROR: "manage (currently on 8.7.x): Must be on one of ['8.11.x', '9.0.x'] to upgrade to MAS 9.1.x"

Testing

✅
All 5 test scenarios passing:

✅ Regular upgrade with --next-channel
✅ Retry scenario (core already upgraded)
✅ Auto-determine without --next-channel
✅ Invalid upgrade path validation
✅ App compatibility validation