docs: add to reviewers guide (#5788)

Description
---
Adds two things to watch out for when reviewing code:
1. Tokio::select Biased
2. Semantic rust functions not handling result types

---------

Co-authored-by: Brian Pearce <[email protected]>

docs/src/reviewing_guide.md

@@ -100,6 +100,25 @@ Tokio has many useful channels, and it can be difficult to know what to look out
    2. When receiving events in a loop, Error::Closed should be used to break out of the loop, because the sender halves have dropped and no more events will be received
    2. Sending to a broadcast `Sender` before there are any receivers (or if they have all dropped) will error. If this is happening on startup, it should be 
 handled gracefully and may succeed in future when a receiver is added.
+3. When using `tokio::select` watch out for `biased` keyword as this can cause the loop to not run certain piece of code. `Biased` causes the loop to be polled in order of the code. If the first items polled will always be ready, the later items will never be run. 
+
+#### Rust function code
+Watch out for functional rust code and ensure that they will not overflow. These functional code brackets don't always allow for error handling. See the following code snippet as an example:
+```rust
+fn sum_kernels(body: &AggregateBody, offset_with_fee: PedersenCommitment) -> KernelSum {
+    // Sum all kernel excesses and fees
+    body.kernels().iter().fold(
+        KernelSum {
+            fees: MicroMinotari(0),
+            sum: offset_with_fee,
+        },
+        |acc, val| KernelSum {
+            fees: acc.fees + val.fee,
+            sum: &acc.sum + &val.excess,
+        },
+    )
+}
+Here is a good example of nice semantic rust code, but the code has the potential to panic and overflow when counting up the fees from the kernels. Semantic RUST is the preferred way of writing code for Tari, it should not come at the determent of safe code. 
 
 #### Behind-the-scenes panics