docs(usage): adjusted daemon usage

docs/pages/v2/usage.mdx

@@ -1,7 +1,5 @@
 # Usage
 
-_Oura_ provides three different execution modes:
+_Oura_ provides one execution mode:
 
 - [Daemon](usage/daemon.md): a fully-configurable pipeline that runs in the background. Sources, filters and sinks can be combined to fulfil particular use-cases.
-- [Watch](usage/watch.md): to watch live block events from a node directly in the terminal. It is meant for humans, it uses colors and throttling to facilitate reading.
-- [Dump](usage/dump.md): to dump live block events from a node into rotation log files or stdout. It uses JSONL format for persistence of the events.

docs/pages/v2/usage/daemon.mdx

@@ -13,7 +13,6 @@ oura daemon
 Available options:
 
 - `--config`: path of a custom toml configuration file to use. If not specified, configuration will be loaded from `/etc/oura/daemon.toml`.
-- `--cursor`: a custom point in the chain to use as starting point. Expects format: `slot,hex-hash`. If not specified, it will look for the [cursor](../advanced/stateful_cursor.md) section available via toml configuration or fallback to the [intersect options](../advanced/intersect_options.md) of the source stage.
 
 Example of starting daemon mode with default config file:
 
@@ -28,12 +27,6 @@ Example of starting daemon mode with a custom config file at `my_config.toml`:
 oura daemon --config my_config.toml
 ```
 
-Example of starting daemon mode specifying a particular cursor:
-
-```sh
-oura daemon --cursor 56134714,2d2a5503c16671ac7d5296f8e6bfeee050b2c2900a7d8c97b36c434667eb99d9
-```
-
 ## Configuration
 
 The configuration file needs to specify the source, filters and sink to use in a particular pipeline. The following toml represent the typical skeleton of an _Oura_ config file:
@@ -60,28 +53,19 @@ type = "Z"
 # custom config fields for this sink type
 foo = "123"
 bar = "789"
-
-# optional cursor settings, remove seaction to disable feature
-[cursor]
-type = "File"
-path = "/var/oura/cursor"
 ```
 
 ### The `source` section
 
-This section specifies the origin of the data. The special `type` field must always be present and containing a value matching any of the available built-in sources. The rest of the fields in the section will depend on the selected `type`. See the [sources](../sources/index.md) section for a list of available options and their corresponding config values.
+This section specifies the origin of the data. The special `type` field must always be present and containing a value matching any of the available built-in sources. The rest of the fields in the section will depend on the selected `type`. See the [sources](../sources) section for a list of available options and their corresponding config values.
 
 ### The `filters` section
 
-This section specifies a collection of filters that are applied in sequence to each event. The special `type` field must always be present and containing a value matching any of the available built-in filters. Notice that this section of the config is an array, allowing multiple filter sections per config file. See the [filters](../filters/index.md) section for a list of available options and their corresponding config values.
+This section specifies a collection of filters that are applied in sequence to each event. The special `type` field must always be present and containing a value matching any of the available built-in filters. Notice that this section of the config is an array, allowing multiple filter sections per config file. See the [filters](../filters) section for a list of available options and their corresponding config values.
 
 ### The `sink` section
 
-This section specifies the destination of the data. The special `type` field must always be present and containing a value matching any of the available built-in sinks. The rest of the fields in the section will depend on the selected `type`. See the [sinks](../sinks/index.md) section for a list of available options.
-
-### The `cursor` section
-
-This section specifies how to configure the [cursor feature](../advanced/stateful_cursor.md). A cursor is a reference of the current position of the pipeline. If the pipeline needs to restart for whatever reason, and a cursor is available, the pipeline will start reading from that point in the chain. Removing the section from the config will disable the cursor feature.
+This section specifies the destination of the data. The special `type` field must always be present and containing a value matching any of the available built-in sinks. The rest of the fields in the section will depend on the selected `type`. See the [sinks](../sinks) section for a list of available options.
 
 ### Full Example
 
@@ -90,19 +74,19 @@ Here's an example configuration file that uses a Node-to-Node source and output
 ```toml
 [source]
 type = "N2N"
-address = ["Tcp", "relays-new.cardano-mainnet.iohk.io:3001"]
-magic = "mainnet"
+peers = ["relays-new.cardano-mainnet.iohk.io:3001"]
+
+[intersect]
+type = "Tip"
 
 [[filters]]
-type = "Fingerprint"
+type = "SplitBlock"
 
 [[filters]]
-type = "Selection"
-predicate = "variant_in"
-argument = ["Block", "Transaction"]
+type = "ParseCbor"
 
 [sink]
 type = "Kafka"
 brokers = ["127.0.0.1:53147"]
-topic = "testnet"
+topic = "mainnet"
 ```