Update MLI docstrings part 2

[AlyssaCote]

Part 2 of docstring updates! Keeping the description as a refresher.

I added and updated the MLI docstrings so that everything renders correctly and they are more consistent. This means I needed to make some decisions on what "consistent" means, because there were many different combinations going on. Feel free to push back on these! I just went with what looked like the best/what we were doing the most.

• The docstring description uses punctuation to end the description.
• The :param:, :returns:, etc do not use punctuation to end their description line UNLESS the line needs multiple sentences, in which case, use punctuation. (I think this happens once or twice).
• All description lines are capitalized.

example:

def serialize_response(response: response_capnp.ResponseBuilder) -> bytes:
   """
   Serializes a built response message.

   :param response: Response to be serialized
   :returns: Serialized response bytes
   """
   return response.to_bytes()

[codecov]

Codecov Report

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

Please upload report for BASE (mli-feature@28bfd8f). Learn more about missing BASE report.

Files with missing lines	Patch %	Lines
...e/mli/infrastructure/control/request_dispatcher.py	0.00%	2 Missing ⚠️
...i/infrastructure/storage/backbone_feature_store.py	0.00%	1 Missing ⚠️

Additional details and impacted files

@@              Coverage Diff               @@
##             mli-feature     #699   +/-   ##
==============================================
  Coverage               ?   69.50%           
==============================================
  Files                  ?      103           
  Lines                  ?     8750           
  Branches               ?        0           
==============================================
  Hits                   ?     6082           
  Misses                 ?     2668           
  Partials               ?        0           

Files with missing lines	Coverage Δ
..._core/mli/infrastructure/control/device_manager.py	0.00% <ø> (ø)
..._core/mli/infrastructure/control/error_handling.py	0.00% <ø> (ø)
..._core/mli/infrastructure/control/worker_manager.py	0.00% <ø> (ø)
...sim/_core/mli/infrastructure/environment_loader.py	0.00% <ø> (ø)
...mli/infrastructure/storage/dragon_feature_store.py	0.00% <ø> (ø)
.../_core/mli/infrastructure/storage/feature_store.py	0.00% <ø> (ø)
smartsim/_core/mli/infrastructure/worker/worker.py	0.00% <ø> (ø)
smartsim/_core/mli/message_handler.py	99.52% <ø> (ø)
...i/infrastructure/storage/backbone_feature_store.py	0.00% <0.00%> (ø)
...e/mli/infrastructure/control/request_dispatcher.py	0.00% <0.00%> (ø)

[al-rigazzi]

Looks great! I have a few comments that I'd like to be addressed and then I think it's good to merge

[al-rigazzi]

What type of error does it raise?

[al-rigazzi]

(if we raise whatever is raised by the underlying call, do we need to document it? Asking because I really don't know what we should do. Should we re-cast the Exception to something we own?)

[AlyssaCote]

Oops I forgot to come back to this one! I actually don't know what error this raises, but I could raise a SmartSimError. As far as what to do about documenting exceptions and where, that's something I'm trying to work through in my error handling ticket as well. If we explicitly raise something here then I think we document it.

[AlyssaCote]

For now, I just did :raises Exception: and I can make the changes to what exactly gets raised in the error handling ticket, if that's okay!

[al-rigazzi]

LGTM, thanks for taking care of those small details I pointed out!