//! Entry point of a Tor relay that is the [`TorRelay`] objects

use std::net::SocketAddr;

use std::path::{Path, PathBuf};

use std::sync::{Arc, Weak};

use anyhow::Context;

use tokio::task::JoinSet;

use tracing::debug;

#[cfg(unix)]

use tracing::warn;

use fs_mistrust::Mistrust;

use tor_basic_utils::iter_join;

use tor_chanmgr::{ChanMgr, ChanMgrConfig, Dormancy};

use tor_config_path::CfgPathResolver;

use tor_dirmgr::DirMgrConfig;

use tor_keymgr::{ArtiNativeKeystore, KeyMgr, KeyMgrBuilder};

use tor_memquota::MemoryQuotaTracker;

use tor_netdir::params::NetParameters;

use tor_persist::state_dir::StateDirectory;

use tor_persist::{FsStateMgr, StateMgr};

use tor_proto::relay::CreateRequestHandler;

use tor_rtcompat::{NetStreamProvider, Runtime};

use crate::client::RelayClient;

use crate::config::TorRelayConfig;

use crate::tasks::channel::build_circ_net_params;

use crate::tasks::crypto::InitKeyMaterial;

/// An initialized but unbootstrapped relay.

///

/// This intentionally does not have access to the runtime to prevent it from doing network io.

///

/// The idea is that we can build up the relay's components in an `InertTorRelay` without a runtime,

/// and then call `init()` on it and provide a runtime to turn it into a network-capable relay.

/// This gives us two advantages:

///

/// - We can initialize the internal data structures in the `InertTorRelay` (load the keystores,

///   configure memquota, etc), which leaves `TorRelay` to just "running" the relay (bootstrapping,

///   setting up listening sockets, etc). We don't need to combine the initialization and "running

///   the relay" all within the same object.

/// - We will likely want to share some of arti's key management subcommands in the future.

///   arti-client has an `InertTorClient` which is used so that arti subcommands can access the

///   keystore. If we do a similar thing here in arti-relay in the future, it might be nice to have

///   an `InertTorRelay` which has these internal data structures, but doesn't need a runtime or

///   have any networking capabilities.

///

/// Time will tell if this ends up being a bad design decision in practice, and we can always change

/// it later.

pub(crate) struct InertTorRelay {

    /// The configuration options for the relay.

    config: TorRelayConfig,

    /// The configuration options for the client's directory manager.

    dirmgr_config: DirMgrConfig,

    /// Path resolver for expanding variables in [`CfgPath`](tor_config_path::CfgPath)s.

    #[expect(unused)] // TODO RELAY remove

    path_resolver: CfgPathResolver,

    /// State directory path.

    ///

    /// The [`StateDirectory`] stored in `state_dir` doesn't seem to have a way of getting the state

    /// directory path, so we need to store a copy of the path here.

    #[expect(unused)] // TODO RELAY remove

    state_path: PathBuf,

    /// Relay's state directory.

    #[expect(unused)] // TODO RELAY remove

    state_dir: StateDirectory,

    /// Location on disk where we store persistent data.

    state_mgr: FsStateMgr,

    /// Key manager. The ownership is shared between the crypto task and the main task

    /// [`TorRelay`].

    ///

    // NOTE: In a future world, would be great if this wouldn't be an Arc<> and we could move it to

    // the crypto task so nobody has access to it. For now, this is the compromise for simplicity.

    keymgr: Arc<KeyMgr>,

}

impl InertTorRelay {

    /// Create a new Tor relay with the given configuration.

        // Try to take state ownership early, so we'll know if we have it.

        // Note that this `try_lock()` may return `Ok` even if we can't acquire the lock.

        // (At this point we don't yet care if we have it.)

    /// Connect the [`InertTorRelay`] to the Tor network.

        // Attempt to generate any missing keys/cert from the KeyMgr.

    /// Create the [key manager](KeyMgr).

        // Should only log fs paths at debug level or lower,

        // unless they're part of a diagnostic message.

        // TODO: support C-tor keystore

}

/// Represent an active Relay on the Tor network.

pub(crate) struct TorRelay<R: Runtime> {

    /// Asynchronous runtime object.

    runtime: R,

    /// Memory quota tracker.

    #[expect(unused)] // TODO RELAY remove

    memquota: Arc<MemoryQuotaTracker>,

    /// A "client" used by relays to construct circuits.

    client: RelayClient<R>,

    /// Channel manager, used by circuits etc.

    chanmgr: Arc<ChanMgr<R>>,

    /// Handles CREATE* requests on channels.

    ///

    /// Given to the [`ChanMgr`],

    /// which gives it to each channel.

    /// We can access this handler directly to update consensus parameters or keys.

    create_request_handler: Arc<CreateRequestHandler>,

    /// See [`InertTorRelay::keymgr`].

    keymgr: Arc<KeyMgr>,

    /// Listening OR ports.

    or_listeners: Vec<<R as NetStreamProvider<SocketAddr>>::Listener>,

}

impl<R: Runtime> TorRelay<R> {

    /// Create a new Tor relay with the given [`runtime`][tor_rtcompat].

    ///

    /// We use this to initialize components, open sockets, etc.

    /// Doing work with these components should happen in [`TorRelay::run()`].

    ///

    /// Expected to be called from [`InertTorRelay::init()`].

        // Init the channel manager.

                // TODO: It seems wrong to start with the compiled-in defaults when we might have

                // a newer network status on disk that would provide a better initial value,

                // but `TorClient` does this too so let's not worry about it.

            )

        );

        // Init the relay's client.

        )

        // Circuit-related network status parameters.

        // A handler that will process CREATE* requests on channels.

        );

        // Configure the channel manager to handle CREATE* requests.

        //

        // We do this once, and can later update its network parameters and keys using the

        // `Arc` handle that we store.

        // The `ChanMgr` will hold an `Arc<CreateRequestHandler>` and

        // the `CreateRequestHandler` will hold a `Weak<ChanMgr>`.

        //

        // We could technically do something fancier by creating the `ChanMgr` and handler

        // inside an `Arc::new_cyclic()` and pass the handler as part of the `ChanMgrConfig`,

        // but the code becomes a mess.

        // We don't use any custom options on the listening socket.

        // An iterator of `listen()` futures with some extra error handling.

                // If we don't support the address family (typically IPv6), only warn.

                #[cfg(unix)]

                    } else {

                        // If we got `EAFNOSUPPORT` for a non-IPv6 address, then warn louder.

                    }

                }

                }

            }

        // We await the futures sequentially rather than with something like `join_all` to make

        // errors more reproducible.

                };

            }

        };

        // Typically we would have returned with an error if we failed to listen on an address,

        // but we ignore `EAFNOSUPPORT` errors above, so it's possible that all failed with

        // `EAFNOSUPPORT` and we ended up here.

    /// Run the actual relay.

    ///

    /// This only returns if something has gone wrong.

    /// Otherwise it runs forever.

        // Channel housekeeping task.

        });

        // Update the CREATE* request handler when there are new network parameters.

        });

        // Listen for new Tor (OR) connections.

                // TODO: Should we give all tasks a `start` method?

        });

        // Start the crypto task.

        });

        // Launch client tasks.

        //

        // We need to hold on to these handles until the relay stops, otherwise dropping these

        // handles would stop the background tasks.

        //

        // These are `tor_rtcompat::scheduler::TaskHandle`s, which don't notify us if they

        // stop/crash.

        //

        // TODO: Whose responsibility is it to ensure that these background tasks don't crash?

        // Should we have a way of monitoring these tasks? Or should the circuit manager re-launch

        // crashed tasks?

        // TODO: More tasks will be spawned here.

        // Now that background tasks are started, bootstrap the client.

        // We block until facism is erradicated or a task ends which means the relay will shutdown

        // and facism will have one more chance.

        // We can never get here since a `Void` cannot be constructed.

}