Implement an FFI to fetch API IP addresses using mullvad-api

[rablador]

We should test out if using the mullvad-api crate is feasible. An FFI that allows for calling out to https://api.mullvad.net/app/documentation/#/paths/~1v1~1api-addrs/get

We should then see if this works when:

• Connected over 4g
• Connected over WiFi
• Connected to a VPN when IAN is set up
• Blocked state when IAN is set up
• Proxies?

Code can be throwaway for now, but if we can make it production ready, we should.

The Swift interface should look similar to the one below:

protocol AddressFetching {
  func fetchApiAddresses() async throws -> [MullvadEndpoint]
}

Said interface would probably have to be implemented by passing a continuation to Rust for when the result is fetched.

/// Swift side for the continuation
struct FFIContinuation {
  let callback: UnsafeMutable<...>
}

@convention(c) func fetch_api_addresses_result(continuation: UnsafePointer<FFIContinuation>)

This task should be owned by an iOS team member, but they should feel free to reach out to any of the Rust developers for help and to pair-program on this task.

As part of this, we should also implement unit tests at least for the Rust parts.

To test that it works, lower updateInterval in AddressCacheTracker to a few seconds to trigger the update of address list. The log should get entries saying Address list: success([45.83.223.196:443]).

---

This change is 

[buggmagnet]

Reviewed 24 of 32 files at r1, 6 of 7 files at r2.
Reviewable status: 29 of 32 files reviewed, 6 unresolved discussions

---

ios/build-rust-library.sh line 57 at r2 (raw file):

      if [ $IS_SIMULATOR -eq 0 ]; then
        # Hardware iOS targets
        rustup target add aarch64-apple-ios

nit
As discussed with the team, this was only a temporary fix for devs, we should remove there 2 new lines.

---

ios/MullvadRustRuntime/MullvadApiCompletion.swift line 16 at r2 (raw file):

    let completionBridge = Unmanaged<MullvadApiCompletion>
        .fromOpaque(completionCookie)
        .takeUnretainedValue()

this should be takeRetainedValue() otherwise we are leaking memory with every request.

---

ios/MullvadVPN/AddressCacheTracker/AddressCacheTracker.swift line 122 at r2 (raw file):

        return Date()
//        return _nextScheduleDate()

Reinstate the commented line

---

ios/MullvadTypes/AsyncExample.swift line 0 at r2 (raw file):
Delete this ?

---

ios/MullvadREST/ApiHandlers/RESTRustNetworkOperation.swift line 149 at r2 (raw file):

extension MullvadApiResponse {
    public func restError() throws -> REST.Error? {

This should either throw or return an Optional value, not both.

---

ios/MullvadRustRuntime/MullvadApiContext.swift line 18 at r2 (raw file):

        if context._0 == nil {
            throw NSError(domain: "", code: 0)

nit
We should have a custom error code that can identify why the request failed maybe ?
This way, debugging potential errors will be less of a hassle

[pinkisemils]

Reviewable status: 29 of 32 files reviewed, 6 unresolved discussions (waiting on @buggmagnet and @rablador)

---

ios/MullvadREST/ApiHandlers/RESTRustNetworkOperation.swift line 149 at r2 (raw file):

Previously, buggmagnet wrote…

This should either throw or return an Optional value, not both.

Should it throw when the request was successful?

[pinkisemils]

Reviewable status: 29 of 32 files reviewed, 6 unresolved discussions (waiting on @buggmagnet and @rablador)

---

ios/MullvadREST/ApiHandlers/RESTRustNetworkOperation.swift line 149 at r2 (raw file):

Previously, pinkisemils (Emīls Piņķis) wrote…

Should it throw when the request was successful?

But you're right, I think this can be made to not throw anymore.

---

ios/MullvadRustRuntime/MullvadApiContext.swift line 18 at r2 (raw file):

Previously, buggmagnet wrote…

nit
We should have a custom error code that can identify why the request failed maybe ?
This way, debugging potential errors will be less of a hassle

This isn't relevant for any one request.

---

ios/MullvadVPN/AddressCacheTracker/AddressCacheTracker.swift line 122 at r2 (raw file):

Previously, buggmagnet wrote…

Reinstate the commented line

This is still a draft PR - we're hoping to discuss the design in it's totality. We of course will not ship this line to end users, but it does help with triggering the API address fetching.

[rablador]

Reviewable status: 29 of 32 files reviewed, 4 unresolved discussions (waiting on @buggmagnet)

---

ios/build-rust-library.sh line 57 at r2 (raw file):

Previously, buggmagnet wrote…

nit
As discussed with the team, this was only a temporary fix for devs, we should remove there 2 new lines.

Done.

---

ios/MullvadREST/ApiHandlers/RESTRustNetworkOperation.swift line 149 at r2 (raw file):

Previously, pinkisemils (Emīls Piņķis) wrote…

But you're right, I think this can be made to not throw anymore.

Done.

---

ios/MullvadRustRuntime/MullvadApiCompletion.swift line 16 at r2 (raw file):

Previously, buggmagnet wrote…

this should be takeRetainedValue() otherwise we are leaking memory with every request.

Done.

---

ios/MullvadTypes/AsyncExample.swift line at r2 (raw file):

Previously, buggmagnet wrote…

Delete this ?

Done.

---

ios/MullvadVPN/AddressCacheTracker/AddressCacheTracker.swift line 122 at r2 (raw file):

Previously, pinkisemils (Emīls Piņķis) wrote…

This is still a draft PR - we're hoping to discuss the design in it's totality. We of course will not ship this line to end users, but it does help with triggering the API address fetching.

I'll keep this in for now.

[rablador]

Reviewable status: 14 of 33 files reviewed, 4 unresolved discussions (waiting on @buggmagnet)

---

ios/MullvadVPN/AddressCacheTracker/AddressCacheTracker.swift line 122 at r2 (raw file):

Previously, rablador (Jon Petersson) wrote…

I'll keep this in for now.

Removed. Description on how to trigger a address list reload has been added to the top description.

[SteffenErn]

Reviewed 1 of 17 files at r4.
Reviewable status: 12 of 33 files reviewed, 4 unresolved discussions (waiting on @buggmagnet)

[SteffenErn]

Reviewable status: 12 of 42 files reviewed, 4 unresolved discussions (waiting on @buggmagnet)

[buggmagnet]

Looks good, but this breaks the UITests build unfortunately.
It looks like it should just be a matter of linking to the correct library in that target, but I haven't looked further

Reviewed 1 of 32 files at r1, 1 of 7 files at r2, 11 of 17 files at r4, 2 of 3 files at r5, 9 of 9 files at r11, 5 of 5 files at r12, all commit messages.
Reviewable status: 41 of 42 files reviewed, 1 unresolved discussion

[buggmagnet]

Reviewable status: 40 of 42 files reviewed, 1 unresolved discussion

[SteffenErn]

Reviewable status: 30 of 54 files reviewed, 1 unresolved discussion (waiting on @buggmagnet)

[SteffenErn]

Reviewable status: 30 of 54 files reviewed, 1 unresolved discussion (waiting on @buggmagnet)

[github-actions]

🚨 End to end tests failed. Please check the failed workflow run.