Add Support for `iroh-net` to Enable Hole Punching

Description
I noticed we are currently using `iroh-blobs` alone. `iroh-blobs` implements a simple request-response protocol. From what I've seen in `iroh` examples, the standard approach is to use `iroh-blobs` together with `iroh-net` for networking support. `iroh-net` is built on direct peer-to-peer [QUIC](https://en.wikipedia.org/wiki/QUIC) connections that use relays and hole punching.

Since our implementation does not use [`iroh-net::Endpoint`](https://docs.rs/iroh/latest/iroh/net/struct.Endpoint.html), it does not support hole punching and will only work locally or between two processes with public IP addresses. This is not the end goal for Ark Drop.

[`sendme`](https://github.com/n0-computer/sendme) is a good example that achieves a similar goal to what we have in mind. It uses [iroh-bytes](https://crates.io/crates/iroh-bytes) and [iroh-net](https://crates.io/crates/iroh-net) to send files and directories over the internet.

For this, we should integrate `iroh-net` into Ark Drop to support hole punching. This will allow the application to work even when the devices are behind NATs or firewalls.

## Testing
Not really sure how this will turn out, but we should have some tests to verify that hole punching works. We should add basic GitHub CI workflows that run with each push/PR.

### Potential solutions
- [`docker-nat-simulate`](https://github.com/zzJinux/docker-nat-simulate): handmade scripts for simulating NAT using Docker containers

Start by tracing the current iroh-blobs integration and comparing it with sendme's use of iroh-net and iroh-bytes. Define tests that verify hole punching through NATs or firewalls, using docker-nat-simulate as a possible test environment, and add GitHub CI workflows that run on pushes and pull requests. Done means the application supports the intended non-local connections and the tests run in CI.

Written by the indexing model from the issue text.