add: limit while scheduling promises

[aneessh18]

This PR addresses the concerns of this issue #169.

More information: right now the kernel processes schedules from the databases every 10 ms and creates promises for execution. It finds out the list of promises to be scheduled by executing the READ_ALL_SCHEDULES query against the respective database. This is prone to occur when the system is under high stress as the query can degrade performance when there are a huge number of promises to be scheduled. Instead, this PR ensures that only a limited number of them are scheduled without the system getting overwhelmed.

Testing

1. I've run the local build and put log statements for recording the number of results in the readSchedules method and I was able to verify that the number of scheduled promises is pegged at the limit.
2. Unit tests

[codecov]

Codecov Report

Attention: Patch coverage is 40.00000% with 3 lines in your changes are missing coverage. Please review.

Project coverage is 57.79%. Comparing base (c73a3b4) to head (6f043d2).
Report is 1 commits behind head on main.

Files	Patch %	Lines
internal/kernel/system/system.go	0.00%	2 Missing ⚠️
...rnal/app/subsystems/aio/store/postgres/postgres.go	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #307      +/-   ##
==========================================
- Coverage   58.46%   57.79%   -0.68%     
==========================================
  Files         113      113              
  Lines        9776     9778       +2     
==========================================
- Hits         5716     5651      -65     
- Misses       3693     3766      +73     
+ Partials      367      361       -6     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[dfarr]

Thank you so much again @aneessh18!!!

Do you mind adding the schedule batch size configuration to our deterministic simulation testing (DST) flags? We would need to add it here, the range flag generates a random number for the config value between the min and the max. It would also be useful to print out this config value here, this helps compare two runs of our DST to ensure that the configuration value is the same.

You can try the DST locally!

go run ./... dst run

[aneessh18]

Thank you so much again @aneessh18!!!

Do you mind adding the schedule batch size configuration to our deterministic simulation testing (DST) flags? We would need to add it here, the range flag generates a random number for the config value between the min and the max. It would also be useful to print out this config value here, this helps compare two runs of our DST to ensure that the configuration value is the same.

You can try the DST locally!

go run ./... dst run

Thanks for reviewing this MR. Added the flags in DST.

[dfarr]

🎉