Add optional bounds type field to GetEntityBounds request

[ayushgnv]

Adds an optional type field to GetEntityBounds.srv so callers can specify their preferred bounding box representation (box, sphere, convex hull). If unset, it defaults to TYPE_UNSPECIFIED (255), preserving existing behavior where the simulator picks the type.

Also adds the TYPE_UNSPECIFIED constant to Bounds.msg as a clean sentinel value for use in requests, distinct from the existing response types.

Closes #26.

[peci1]

Is there some real use case for autoselection of the bounds type? I can't really imagine downstream code asking for "some" bounds.

But I agree with the addition of the type to the request

[ayushgnv]

Is there some real use case for autoselection of the bounds type? I can't really imagine downstream code asking for "some" bounds.

But I agree with the addition of the type to the request

@peci1
I was not sure if all simulators should be forced to support one of the types such as TYPE_BOX by default. A simulator could choose to have a different default from other simulators and so that's where this auto selection option might comes in handy.

If we agree as a standard to support a default type for all simulators, I'm happy with setting this option to that default type moving forward.

[zakmat]

I like this feature and see the value.

In current shape, however, it is a breaking ABI change. Which means we will have problems backporting it into released distros.

I strongly suggest keeping consistent interface across distros.
Some approaches to consider, @ayushgnv what's your take?

• Use separate service to configure returned BOUNDS_TYPE and continue to use existing service
• Create a new service that supersedes GetEntityBounds. We could either keep both and make the new field required, or deprecate the old one.

Also how about promoting supported bounds types into own simulator features?

Regarding the default i vote for TYPE_BOX

[zakmat]

Changing struct layout is ABI-breaking change, we could not back-port it into released distros. It means Jazzy won't get it. The time window for Lyrical is also limited.

I strongly suggest creating a separate, new service for that feature.
We could mark this one as deprecated as well