(Partially) Remove 30000

[shjortConcordium]

Purpose

Remove some of the hardcoded 30000 energy on contract updates.

Changes

Removed 30000 energy from updates in the wCCD, voting and eSealing dApps

Checklist

• My code follows the style of this project.
• The code compiles without warnings.
• I have performed a self-review of the changes.
• I have documented my code, in particular the intent of the
  hard-to-understand areas.
• (If necessary) I have updated the CHANGELOG.

[DOBEN]

Adding a small margin EPSILON_ENERGY will help in cases where someone else uses the front end at the same time and the state of the smart contract has changed between the simulation and the execution of the transaction.

    const maxContractExecutionEnergy = Energy.create(dryRunResult.usedEnergy.value + EPSILON_ENERGY);

https://github.com/Concordium/concordium-dapp-examples/blob/main/trackAndTrace/frontend/src/track_and_trace_contract.tsx#L63

Applies to the other examples below as well.

[DOBEN]

It would be helpful if that error message reports the reason for the failure. The following, I suggest to cover:

• Return the rejectReason of the smart contract if present.
• Return the invokeResult.tag (if it is not failure) since that is where we can see OutOfEnergy errors:
  https://github.com/Concordium/concordium-smart-contract-tools/blob/main/front-end-tools/src/utils.ts#L209

    const fullEntryPointName = `${contractName.value}.${entryPoint.value}`;

    if (!res || res.tag === 'failure') {
        const rejectReason = JSON.stringify(
            ((res as InvokeContractFailedResult)?.reason as RejectedReceive)?.rejectReason
        );

        throw new Error(
            `RPC call 'invokeContract' on method '${fullEntryPointName}' of contract '${contractIndex}' failed.
            ${rejectReason !== undefined ? `Reject reason: ${rejectReason}` : ''}`
        );
    }

Reason for adding this reporting of errors now:
Before, people who reported problems while using this front end were able to give us a "failedTransactionHash" that we could use for further investigation. We don't have this anymore, so reporting potential problems here is what we have to rely on now.

This comment applies to the other examples as well.

[soerenbf]

@DOBEN are you taking lead on this? We should ideally also either

• deploy these, or
• roll back the version bumps until we do deploy them