chore: implement consensus mechanism (#43)

* chore: implement consensus mechanism

- Updated `Cargo.lock`
- Refactored `Cargo.toml`
- Enhanced `action_handlers.rs` to introduce a ban request feature, allowing users to send ban requests through Waku.
- Implemented a new consensus module to manage proposal and voting processes, including state transitions for steward epochs.
- Updated error handling in `error.rs` to accommodate new consensus-related errors.
- Refactored `group.rs` and `user_actor.rs` to integrate the new consensus logic and improve state management.
- Added tests for the consensus mechanism to ensure reliability and correctness of the voting process.

* chore: update dependencies and refactor code for clarity

* refactor: update voting mechanism and clean up user actor logic

- Changed the return type of `complete_voting_for_steward` to return a vector of messages instead of a boolean.
- Removed unused request types and their implementations related to proposal handling.
- Updated the `handle_steward_flow_per_epoch` function to reflect changes in the voting process and improved logging.
- Refactored tests to align with the new voting mechanism and ensure proper message handling.
- Enhanced consensus logic to better handle vote counting and state transitions.

* feat: implement real voting for all users

- Improved logging messages for clarity during WebSocket message handling.
- Added new serverless functions and shims for better integration with the frontend.
- Introduced new manifest files for server configuration and routing.
- Implemented initial setup for handling user votes and proposals in the consensus mechanism.
- Updated error handling to accommodate new user vote actions and related messages.

* consensus: update test

* Enhance steward state management and consensus mechanism

- Added detailed documentation in README for steward state management, including state definitions, transitions, and flow scenarios.
- Updated `WakuNode` connection logic to include a timeout for peer connections.
- Refactored message handling in `action_handlers.rs` to utilize new `AppMessage` structures for improved clarity.
- Enhanced error handling in `error.rs` to cover new scenarios related to consensus and state transitions.
- Updated tests to reflect changes in the consensus mechanism and steward flow, ensuring robustness and reliability.
- Improved state machine logic to handle edge cases and guarantee proper state transitions during steward epochs.

* Refactor

- Updated `WakuMessageToSend` constructor to accept a slice for `app_id`, improving memory efficiency.
- Enhanced error handling in `Group` struct to provide more descriptive error messages for invalid states.
- Added detailed documentation for new methods in `Group` and `User` structs, clarifying their functionality and usage.
- Refactored state machine logic to ensure proper transitions during steward epochs and voting processes.
- Improved test coverage for group state management and message processing, ensuring robustness in various scenarios.

* Update README for improved clarity and formatting

* fix: fix lint issues and updates test flow

* test: update user test

README.md

@@ -2,7 +2,8 @@
 
 Decentralized MLS PoC using a smart contract for group coordination
 
-> Note: The frontend implementation is based on [chatr](https://github.com/0xLaurens/chatr), a real-time chat application built with Rust and SvelteKit
+> Note: The frontend implementation is based on [chatr](https://github.com/0xLaurens/chatr),
+> a real-time chat application built with Rust and SvelteKit
 
 ## Run Test Waku Node
 
@@ -44,6 +45,48 @@ Run from the root directory
 RUST_BACKTRACE=full RUST_LOG=info NODE_PORT=60001 PEER_ADDRESSES=/ip4/x.x.x.x/tcp/60000/p2p/xxxx...xxxx,/ip4/y.y.y.y/tcp/60000/p2p/yyyy...yyyy cargo run --  --nocapture
 ```
 
+## Steward State Management
+
+The system implements a robust state machine for managing steward epochs with the following states:
+
+### States
+
+- **Working**: Normal operation where all users can send any message type freely
+- **Waiting**: Steward epoch active, only steward can send BATCH_PROPOSALS_MESSAGE
+- **Voting**: Consensus voting phase with only voting-related messages:
+  - Everyone: VOTE, USER_VOTE
+  - Steward only: VOTING_PROPOSAL, PROPOSAL
+  - All other messages blocked during voting
+
+### State Transitions
+
+```text
+Working --start_steward_epoch()--> Waiting (if proposals exist)
+Working --start_steward_epoch()--> Working (if no proposals - no state change)
+Waiting --start_voting()---------> Voting
+Waiting --no_proposals_found()---> Working (edge case: proposals disappear)
+Voting --complete_voting(YES)----> Waiting --apply_proposals()--> Working
+Voting --complete_voting(NO)-----> Working
+```
+
+### Steward Flow Scenarios
+
+1. **No Proposals**: Steward stays in Working state throughout epoch
+2. **Successful Vote**:
+   - **Steward**: Working → Waiting → Voting → Waiting → Working
+   - **Non-Steward**: Working → Waiting → Voting → Working
+3. **Failed Vote**:
+   - **Steward**: Working → Waiting → Voting → Working  
+   - **Non-Steward**: Working → Waiting → Voting → Working
+4. **Edge Case**: Working → Waiting → Working (if proposals disappear during voting)
+
+### Guarantees
+
+- Steward always returns to Working state after epoch completion
+- No infinite loops or stuck states
+- All edge cases properly handled
+- Robust error handling with detailed logging
+
 ### Example of ban user
 
 In chat message block run ban command, note that user wallet address should be in the format without `0x`