Boot prefixes not updated when user selects different Boot version

[onobc]

Steps to reproduce

1. Fresh SCDF 2.11.0 install
2. Register task2 apps

   task.timestamp=maven://io.spring:timestamp-task:2.0.2
   task.timestamp.bootVersion=2
   task.timestamp-batch=maven://io.spring:timestamp-batch-task:2.0.2
   task.timestamp-batch.bootVersion=2
   

3. Register task3 apps

   task.timestamp=maven://io.spring:timestamp-task:3.0.0
   task.timestamp.bootVersion=3
   task.timestamp-batch=maven://io.spring:timestamp-batch-task:3.0.0
   task.timestamp-batch.bootVersion=3
   

4. Make task3 apps the default (manage versions view)
5. Create simple timestamp task definition timestamp w/ name "taskTwo"
6. Choose launch task
7. In launch view notice the default version (boot3) is pre-selected - keep that selection
8. Click "Launch Task"
9. VERIFY: In task execution view that is shown, prefixes must be BOOT3
10. Select "Relaunch Task"
11. In launch view, notice the prefix properties are shown w/ expected boot3 values.
12. Select the boot2 version of the app in the drop-down.
    PROBLEM: The prefix properties are not updated (still show boot3).
13. Click "Launch Task"
14. VERIFY: In task execution view that is shown, prefixes must be BOOT2

GOOD: Even though the UI shows incorrect prefixes, the backend uses the proper BOOT2 prefixes.

[claudiahub]

@onobc I've verified this using dataflow server v. 2.11.0 .
If I go through all the steps, after updating the app version from 3.0.0 to 2.0.2 I am able to see the launch view with the updated boot2 prefixes as expected.
See screenshot below. The only thing relevant to be worked is the dropdown in the launch view but this is tracked here #5469.

Maybe you're referring to other prefixes in another view ?

[corneil]

The following list of properties are determined by the backend and cannot be set by the user.
spring.cloud.task.schemaTarget, spring.cloud.task.tablePrefix,spring.cloud.deployer.bootVersion, spring.batch.jdbc.table-prefix, spring.batch.jdbc.tablePrefix
I would suggest removing the following properties when the version changes or at the start of launch.

[onobc]

If they truly can never be set by the end user it would make sense to not surface them.

[markpollack]

closed in favor of #5482