Provide a LookupTransform service

We are having performance issues maintaining separate TransformBuffers in every node we spin and want to switch to tf2_ros_py.BufferClients with a central buffer running in the background instead.

Example use case:

We have a node checking if the robot "teleported" due to localization errors every 5 seconds. Using a separate Buffer + Listener, this node has to process every /tf message and takes almost 25% of a CPU core on a Ryzen 5 5600X when a lot of TF messages are swarming in.

Action vs. Service

However, the buffer server is currently implemented as an action server. @sloretz also commented:

https://github.com/ros2/geometry2/blob/141e3cb732e5c4dba744abac381c8317ffb286f0/tf2_ros_py/tf2_ros/buffer_client.py#L208-L209

Using an action server seems like a unnecessary overhead for something that is supposed to be used to reduce the computational cost of an own Buffer + Listener and also the wrong choice, given the result of the request should be either directly available or fail.

On a second node, the tf2_ros.BufferClient creates a new thread for every request to the Action client, yet still blocks the calling thread:

https://github.com/ros2/geometry2/blob/141e3cb732e5c4dba744abac381c8317ffb286f0/tf2_ros_py/tf2_ros/buffer_client.py#L239-L242

Is there a reason against just using event.wait with a timeout? (See https://docs.python.org/3/library/threading.html#threading.Event.wait ) I think this can't be the most efficient way to just get 3+4 floats from another node.

Is there a specific reason for this choice? Otherwise it would be good to (also) provide a simple service.

Start by reading tf2_ros_py/tf2_ros/buffer_client.py, especially the linked action-client implementation and its request-waiting behavior. Trace the existing buffer server and lookup request path to determine the service interface and compatibility needs. Done means a simple LookupTransform service is available with coverage for successful and failed requests.