Bug when staking address and activity checker address do not match (non-staking)

[jmoreira-valory]

Description of the bug

The trader requires a correct configuration for staking contracts even if it's not staked. In other words, if there is provided an invalid pair of (STAKING_CONTRACT_ADDRESS, MECH_ACTIVITY_CHECKER_CONTRACT) the agent will indefinitely loop in the CallCheckpointRound. This may happen in several circumstances:

1. STAKING_CONTRACT_ADDRESS is set to a 'dummy' value (e.g., all-zero address): The service will fail to call the contract to know the staking state.
2. STAKING_CONTRACT_ADDRESS is set to a V2 staking contract, but MECH_ACTIVITY_CHECKER_CONTRACT is set to all-zero address: The service will also fail to call the contract, as it will use STAKING_CONTRACT_ADDRESS as V1 staking contract (the service differentiates V1 vs V2 contracts deppending whether MECH_ACTIVITY_CHECKER_CONTRACT is all-zeros or not.

This custom logic seems somewhat error prone, as in order to work, even if the service is not staked, it requires that these 2 variables are tuned in a very specific way:

either

STAKING_CONTRACT_ADDRESS is set to a V1 address AND MECH_ACTIVITY_CHECKER_CONTRACT is set to all-zero address.

or

STAKING_CONTRACT_ADDRESS is set to a V2 address AND MECH_ACTIVITY_CHECKER_CONTRACT is set to the corresponding staking contract activity checker.

It is somewhat counterintuitive and convoluted that a non-staking user has to be aware of these restrictions to properly set their variables.

Suggestions to fix it

1. If the STAKING_CONTRACT_ADDRESS is set to a placeholder value (e.g., all-zero address) then assume the service is not staked and skip any staking contract interactions. Do not force the service to cycle in the wrong state.
2. If STAKING_CONTRACT_ADDRESS is set to a wrong contract address, proceed as in step 1, assuming the service is not staked. Otherwise, launch some exception and terminate with an error message.
3. If STAKING_CONTRACT_ADDRESS is a valid staking contract, the service logic should be able to determine if it's a V1 or V2 contract (as mentioned above, the current approach of setting an environment variable (MECH_ACTIVITY_CHECKER_CONTRACT) to all-zeros or not, is not very robust). The service should call for the presence of the method activityChecker in the contract.
   a. If staking contract is a proxy, then call getImplementation.
   b. If implementation does not contain activityChecker then, it's V1 contract -> set activity_checker = staking_contract
   c. If implementation contains activityChecker then it's V2 contract -> set activity_checker = staking_contract.activityChecker()