Update bridge framework tests

[andygolay]

Description

In aptos-move/e2e-move-tests/src/tests/bridge.rs:

• Update test_counterparty so anyone with the pre-image can call atomic_bridge_counterparty::complete_bridge_transfer
• Update test_initiator so initiator calls atomic_bridge_initiator::complete_bridge_transfer
• Add test_refund and test_abort

In aptos-move/framework/aptos-framework/sources/atomic_bridge.move:

• Remove assert_is_caller_operator(caller); from atomic_bridge_initiator::complete_bridge_transfer (see the corresponding fun in our audited module: https://github.com/movementlabsxyz/movement/blob/main/protocol-units/bridge/move-modules/sources/atomic_bridge_initiator.move)
• Remove test_complete_bridge_transfer_by_sender
• Add test_complete_bridge_transfer_timelock_expired

Type of Change

• [ x] New feature
• [ x] Bug fix
• Breaking change
• Performance improvement
• Refactoring
• Dependency update
• Documentation update
• Tests

Which Components or Systems Does This Change Impact?

• Validator Node
• Full Node (API, Indexer, etc.)
• Move/Aptos Virtual Machine
• [ x] Aptos Framework
• Aptos CLI/SDK
• Developer Infrastructure
• Other (specify)

How Has This Been Tested?

• Move unit tests: movement move test
• Rust E2E tests: cargo test bridge

Key Areas to Review

• If there is some security reason why only the bridge operator should be allowed to call atomic_bridge_initiator::complete_bridge_transfer, then we should update our audited modules. However, I don't see why it would be an issue, if the counterparty lock and abort calls are restricted to the operator.

Checklist

• [ x] I have read and followed the CONTRIBUTING doc
• [ x] I have performed a self-review of my own code
• [ x] I have commented my code, particularly in hard-to-understand areas
• [ x] I identified and added all stakeholders and component owners affected by this change as reviewers
• [ x] I tested both happy and unhappy path of the functionality
• [ x] I have made corresponding changes to the documentation

[mzabaluev]

Looks good, though I don't feel knowledgeable enough to approve.

Should we enroll these tests into the CI?
The story of GitHub workflows in this fork is that we removed anything from upstream that wasn't consciously used by us. But any workflow from the main branch can be picked up and adapted to run on movement, including those that ran the move tests.

[andygolay]

Looks good, though I don't feel knowledgeable enough to approve.

Should we enroll these tests into the CI? The story of GitHub workflows in this fork is that we removed anything from upstream that wasn't consciously used by us. But any workflow from the main branch can be picked up and adapted to run on movement, including those that ran the move tests.

Yes good point, I believe @andyjsbell is looking into how to fix up the CI.