Fix deployment of program-v4 in freshly started test validator

[pgarg66]

Problem

Failure in deploying program-v4 in freshly started test-validator.

Summary of Changes

• The deployment slot for a program is initialized to 0 during initialization.
• The loader checks if the current slot is > deployment slot + cooldown slots. If not, it fails the deployment.
• The test-validator starts from slot 0. So if someone tries to deploy a program within cooldown slots after startup, the above condition fails.
• This PR skips checking the cooldown slot if the deployment slot is 0. As it indicates the program was just initialized but never deployed.

Fixes #

[Lichtso]

But doesn't that mean that you can redeploy as often in slot 0 as TXs fit inside the block?
Not that it matters much, just saying.

[pgarg66]

But doesn't that mean that you can redeploy as often in slot 0 as TXs fit inside the block? Not that it matters much, just saying.

Once it's deployed, the state.slot will not be 0 (unless deployed in slot 0 itself). So the other condition will take over.
So yes, in slot 0 it can be deployed multiple times.

We can change it to an Option. That should be able to differentiate between initial value and value after deployment. Wdyt?

[codecov]

Codecov Report

Merging #33583 (bf08e79) into master (c588f25) will decrease coverage by 0.1%.
The diff coverage is 100.0%.

@@            Coverage Diff            @@
##           master   #33583     +/-   ##
=========================================
- Coverage    81.7%    81.7%   -0.1%     
=========================================
  Files         807      807             
  Lines      218283   218283             
=========================================
- Hits       178485   178464     -21     
- Misses      39798    39819     +21     

[pgarg66]

But doesn't that mean that you can redeploy as often in slot 0 as TXs fit inside the block? Not that it matters much, just saying.

Once it's deployed, the state.slot will not be 0 (unless deployed in slot 0 itself). So the other condition will take over. So yes, in slot 0 it can be deployed multiple times.

We can change it to an Option. That should be able to differentiate between initial value and value after deployment. Wdyt?

@Lichtso I thought some more about using an Option for the slot. It's doable but will complicate the logic for computing LoaderV4State from the program's account data. It might be better to keep the current logic with the caveat of special casing of the slot 0.