Avoid putting the game in a broken state if invalid turbo settings are submitted for fire-assisted attack

[cgolubi1]

• Partially addresses stuck game on prod site #2967

This is the simplest possible fix for the root cause.

Background:

• Fire-assisted attacks are performed in two parts, first setting up the attack for fire turndown, and then the fire turndown happens and the attack is committed
• Setting turbo values always happens after the attack is resolved.
• Because in the UI the turbo values are set on the first screen, we cache those values from submitTurn, and then get them out of the cache and apply them when we adjust fire dice.

The reason we get games into a broken state, is simply that the fire-adjusted path has its own implementation of applying turbo values, and it doesn't check the return value from set_turbo_sizes(), such that if set_turbo_sizes() fails, we just plow on ahead, and importantly, we plow on ahead to save_game(), committing the broken state in the DB.

This is the simplest possible fix --- it checks the return value, and tells the player if it failed. And it does work (i'm attaching some screencaps below), because if the player abandons the fire turndown, that abandons the cached turbo values, and the player can start over.

It's not the most user-friendly --- it would be marginally more friendly if we rejected the turbo values on the initial screen, rather than making the player back their attack out. However, i think we should stick with this, because:

• This is the first time we've heard of a player actually running into this case, and we're several years into supporting Turbo+Fire
• Detecting the problem on the first screen would require something different would require something like the BMAttackTrip::attacker_apply_turbo() workflow where we optimistically apply the turbo changes on cloned dice just to test them. That's more complexity and more opportunity to introduce errors; since the player can rescue themselves with this fix, it doesn't seem worth it.

[dev site: https://2967-invalid-turbo-swing-fire.cgolubi1.dev.buttonweavers.com/ui/ ]

[blackshadowshade]

This looks like a pretty simple fix. I figure we fire up a dev site for it and take a look.

[cgolubi1]

Demonstrating this fix, in six screencaps:

[blackshadowshade]

Looks good. If we can get testers on the dev site to replicate that behaviour, I'm happy to approve this as-is.

[cgolubi1]

Dev site is up at https://2967-invalid-turbo-swing-fire.cgolubi1.dev.buttonweavers.com/ui/ --- please take a look!

[blackshadowshade]

Still looking for testers to give this a go.

[PoshFrosh]

Dev site is up at https://2967-invalid-turbo-swing-fire.cgolubi1.dev.buttonweavers.com/ui/ --- please take a look!

@blackshadowshade @cgolubi1
I learned about this on discord and gave it a shot. Game 502:

[dwvanstone]

I've tested this as well -- including the case of fire overshooting on a power attack (with turbo). It looks good.

[blackshadowshade]

Thank you for testing, both of you!

[cgolubi1]

@blackshadowshade what else does this need before you'd be good to merge it?

[blackshadowshade]

Thank you for the reminder, merging now.