Monte Carlo Base

[shihaocao]

Before opening the PR, think:

• Is this PR bulletproof? Can I think of no ways to improve this PR beyond its current state?
• Is the PR short enough to ensure a quick but thorough review, but long enough to represent a complete feature? For large state machines, let's try opening PRs for only a few states at a time.

If the answer to either of these questions is "no", refactor your code and open your PR when the answer to both questions is "yes".

---

PR Title

Fixes #. (Optional; sometimes PRs don't have an associated ticket)

Summary of changes

If it applies, take a chance to describe offshoot work or TODOs that are a part of your PR.

Testing

Describe your unit and functional testing. The testing should be at a level appropriate to demonstrate that your feature is sufficiently tested.

If you've got HITL or HOOTL run logs, the logs should go under the "Pull Request HITL Logs" folder on the OneDrive. Create a new subfolder with the # of this PR and put your items there. Note: the logs can be found after ptesting at ptest/logs (pick the appropriately dated folder for the log containing a successful run.)

The logs can be read via the ptest standalone plotter utility. See ptest/ for more details.

If your update does not require significant testing, argue why, or if you're deferring testing to another PR, create an issue ticket for the deferral and link it.

Constants

Describe any important diffs to the constants file in the root level of the repository. Ensure that any constants you added to the code successfully made it into the constants file. If not, wrap the missing constants with TRACKED_CONSTANT macros and fix constants_reporter.py if necessary.

Telemetry

Describe any important diffs to the telemetry file in the root level of the repository. Ensure that any telemetry you added to the code successfully made it into the telemetry file.

Also, take the opportunity to add the telemetry into the appropriate flows in src/flow_data.csv.

Documentation Evidence

Post to ReadTheDocs, or

• Argue that your inline documentation is sufficient.
• Create a issue ticket deferring the documentation task.

[shihaocao]

Closing, will be merged with pro PR