PMM-7 Refactor launchSpotInstance function

[ademidoff]

• Refactored and improved the spot instance launch logic, including a new or updated runSpotInstance.groovy with significant optimizations, such as removal of the second volume which was not being mounted and used.
• Adjusted pmm3-aws-staging-start.groovy with various fixes, cleanups, and improvements.
• Removed the comment from pmm3-release-candidate.groovy.
• Added or updated helper scripts: getPMMBuildParams.groovy (new), getSSHKeys.groovy (updated), and a minor fix in getSHHKeysPMM.groovy.
• The changes include both code cleanups and functional improvements, especially around library usage and spot instance management.

[nogueiraanderson]

@ademidoff The DAYS variable is used in runSpotInstance.groovy at line 117 but it's not passed as a parameter to the function.

Key=stop-after-days,Value=${DAYS} ```

This variable appears to be expected from the calling context, but it would be better to pass it as an explicit parameter to the `runSpotInstance` function for clarity and to avoid potential undefined variable errors.

[nogueiraanderson]

The library reference needs to be updated before merging:

library changelog: false, identifier: 'v3lib@PMM-7-refactor-launch-spot-instance-fn', retriever: modernSCM(

This should be changed back to 'v3lib@master' at line 6 in pmm/v3/pmm3-aws-staging-start.groovy before merging this PR, otherwise the pipeline will fail when the feature branch is deleted.

[ademidoff]

The library reference needs to be updated before merging:

library changelog: false, identifier: 'v3lib@PMM-7-refactor-launch-spot-instance-fn', retriever: modernSCM(

This should be changed back to 'v3lib@master' at line 6 in pmm/v3/pmm3-aws-staging-start.groovy before merging this PR, otherwise the pipeline will fail when the feature branch is deleted.

Done.

[ademidoff]

@ademidoff The DAYS variable is used in runSpotInstance.groovy at line 117 but it's not passed as a parameter to the function.

Key=stop-after-days,Value=${DAYS} ```

This variable appears to be expected from the calling context, but it would be better to pass it as an explicit parameter to the `runSpotInstance` function for clarity and to avoid potential undefined variable errors.

We have a number of global variables, that are necessary to run such pipelines - VM_NAME, DAYS, and OWNER. They are used in many places and therefore fixing the function signatures would be out of scope of this ticket.

I do agree that explicitly passing the variables is much easier to reason about and support, but that would be require us to make changes to almost every other pipeline and then test them all.