feat(SpokePool): Initialize depositId

[nicholaspai]

Constructor should be able to initialize deposit ID to support upgrades

The alternative implementation with less code diff would be to add an admin function incrementDepositCount(uint32 count) where the admin could increase the deposit count. I don't see this being useful outside of upgrades so I decided not to do it.

Thoughts?

[mrice32]

LGTM!

Interesting comment on the admin call.
Advantages:

• More flexibility.

Disadvantages:

• More complexity.
• Possible to "skip" deposit ids in a single spoke pool. In the future, we could use skips as a sign that we missed a deposit/fill in the bots, but if these can be incremented after launch, that strategy wouldn't really work as nicely.

I can't think of a reason we'd want to do this. Can you @pxrl?

[pxrl]

An alternative solution could be to have the contract pause deposits automatically in the constructor, which would then allow the depositId to be manually adjusted via a separate txn, before unpausing again. This might make it marginally easier to re-deploy successive contracts because it'd be one less thing to modify each time.

FWIW as background, I like the concept of the contract being deployed in a "guarded" state to allow time for any manual post-deployment testing and config, before flicking a switch to make it accessible to all others.

[nicholaspai]

An alternative solution could be to have the contract pause deposits automatically in the constructor, which would then allow the depositId to be manually adjusted via a separate txn, before unpausing again. This might make it marginally easier to re-deploy successive contracts because it'd be one less thing to modify each time.

FWIW as background, I like the concept of the contract being deployed in a "guarded" state to allow time for any manual post-deployment testing and config, before flicking a switch to make it accessible to all others.

This is the case today as enabledDeposits for all indices will be false