Refactor go-f3 to Separate Simulation Code from GPBFT Library Implementation

[masih]

The go-f3 library is designed to implement the GPBFT algorithm and is currently being prepared for integration with Lotus. Originally developed as a simulator, the library includes a sim package and other related packages used primarily for stress testing the implementation.

The presence of simulation-related packages within the production scope increases the API surface unnecessarily and potentially elevates the risk of errors. This configuration is not ideal for a production environment where a leaner, more secure implementation is preferable.

Proposed Solutions:

• Move Simulation-Related Code to Test Scope: This would involve relocating the sim package and any other non-essential packages to the test directories. This reorganisation will clarify that these packages are intended for testing and not for production use.

• Separate Simulator into a Different Go Module: By creating a distinct module for the simulator, the GPBFT implementation can reduce its exported APIs, focusing solely on functionalities critical to its operation.

Either way, the changes should streamline the library, minimising the exposed API surface and reducing the scope for errors for a smoother integration with Lotus.

[anorth]

I'm not familiar with Go workspaces, but I've heard you talk about them. Can we use them here to keep this code in one repository but separate logical modules? If so, sounds great.