Potential bug in AttestationImpl::attest

[hudem1]

Hi,

I was going through the staking & attestation contracts, and I believe I might have found a potential bug.

In the function attest here in the statement:

let staking_attestation_info = staking_dispatcher
    .get_attestation_info_by_operational_address(:operational_address);

I believe this might create a bug, because:

1. This might retrieve the staking_attestation_info for an epoch greater than the one in which the validator called get_attestation_info_by_operational_address to compute its block number to attest to. For example, that would be the case if a validator ends up sending the attestation in the following epoch as maybe its block to attest to was very late in the epoch and/or the attestation_window was big.

2. Even if the validator called attest in the same epoch of the block it attested to, we could have this sequence of actions:
   2.1. A validator calls get_attestation_info_by_operational_address & get_attestation_window (to compute the block number to attest to).
   2.2. An update to EpochInfo is done (EpochInfoTrait::update) updating the length, and/or an update to attestation_window is done.
   2.3. The validator sends its attestation for the epoch (AttestationImpl::attest).

   In that 2nd scenario, that call above (in the code snippet) would get the new epoch length and/or the new attestation window (effective from the next epoch) whereas the validator actually got the previous epoch's length/attestation_window. As a consequence, the expected block number computed by the contract would end up being different than the one the validator computed.

These observations are based on the fact starkware is expecting validators to call get_attestation_info_by_operational_address & get_attestation_window to compute their respective block to attest to. Please correct me if my understanding is erroneous.