[Sprint] Improve caching mechanism

[younik]

This PR goes a bit beyond what we agreed, so feel free to reject it. I can easily do a simpler version where we call update_cached inside the reset function.

The motivation is that update cached was always called after data.replace (and the cached values are needed at every step), so it probably makes sense to compute it during data construction and at every replace.

The reset_ methods are calling a replace, which is an expensive operation. This is not immediately clear to the user, and leads to sequentially reset calls:

data.reset_base_position(...)
data.reset_base_velocity(...)
...

One method that allows to change multiple things would be better, so I used the replace itself.

The other selling point is that with the current solution, we need to remember to call update_cached from now on, which may lead to future bugs.

One negative aspect of this is that we need model in replace, which differs from the dataclass.replace as the model is not an attribute of data.

---

📚 Documentation preview 📚: https://jaxsim--359.org.readthedocs.build//359/

[flferretti]

Thanks a lot @younik, it looks to me overall. It does make sense to remove the reset_* methods, but the problem is that we are storing some quantities in VelRepr.Inertial, so we either need to add a comment to make this clear to the user, or to change the cached quantities in the same velocity representation of the JaxSimModelData instance

[flferretti]

Adding typing.override decorator would prevent in the future errors related to overriding methods from parent class

Suggested change

	def replace(
	@override
	def replace(

[younik]

done!

[xela-95]

Thanks @younik ! The replace approach in which to update the cached values is elegant to me and avoid potential future issues! I added some comments related to the handling of data attributes and their representation.

[xela-95]

now data.base_orientation return a quaternion

Suggested change

	W_R_B = data.base_orientation
	W_Q_B = data.base_orientation

[younik]

done!

[xela-95]

forward kinematics works only in inertial (this has been made more clear in #361 , so we need to convert base linear and angular velocities to this representation before calling it.

[younik]

good catch, done!

[xela-95]

@younik I noted that here we also miss a property for the base transform, since it is only cached as a private attribute.