RSDK-6170 - add debug log support

[stuqdog]

Adds support for server-side debug logging.

Note to reviewers: this PR gets us 90+% of the way to where we want to be. The problem is that a few methods (get_properties and is_moving, e.g.) do not take extra as a param. I spent some time brainstorming but I don't see a way to support adding debug logs for these without adding new params to the methods (which would be breaking). Even if we decided to break things, we'd either have to add extra to these (which would be misleading to users) or add a special field to these (which would have unclear/ambiguous utility to many implementers and would create inconsistency in our implementation that could be confusing for users). As such, I've opted to go with the "good enough" approach; we can cross this bridge if/when if a user desperately needs debug log support for these particular methods sometime in the future.

example code:

#include <viam/sdk/common/proto_type.hpp>
#include <viam/sdk/components/motor.hpp>

auto robot = connect();

auto m = robot->resource_by_name<Motor>("<my-motor-name>");
// "my-cool-key" is optional; if not provided, a random key will be created
AttributeMap with_key = debug_map("my-cool-key"); 
// alternatively if you already have a map you could call `add_debug_entry(my_map, "my-cool-key");` 
m->go_for(100, 2, with_key);

example output:

Flybys:

• remove some include/using invocations
• Add extra-less, inline Arm::move_to_joint_positions

[stuqdog]

@dgottlieb fyi!

[stuqdog]

Just noticed that the commit hash starts with 993355757. which isn't important at all but I kinda like it.

[lia-viam]

Mostly minor changes, maybe we should also add a change to one of the unit tests using a peek_debug_key parameter or similar?

[lia-viam]

slight typo with the close paren

[lia-viam]

This and the one above should probably pass the parameter in the same way?

[stuqdog]

Hmm maybe you can help me out here! I have an add_debug_entry that passes the param the same way above, but with just those two I get compilation errors (candidate function not viable: expects an rvalue for 1st argument). Having the "pass by value" version fixed that, though perhaps it shouldn't be exposed to users?

[stuqdog]

actually nevermind! I think after I rebase with your ProtoStruct changes this issue goes away :)

edit: actually maybe not haha, we'll see!

edit edit: okay std::move okay I think we're good.

[lia-viam]

Suggested change

	return debug_map(debug_key);
	return debug_map(random_debug_key());

[stuqdog]

looks like this suggestion doesn't remove the debug_key variable creation so I'm modifying locally and pushing, but will make this change!

[lia-viam]

oops yes haha limitation of github inline code suggestions

[lia-viam]

ok sorry for the bikeshedding but the parameter passing thing got me thinking, maybe we should rename add_debug_entry and/or add an extra overload? If I have a class Meow I would expect a function with "add" in the name to mutate it like add_entry(Meow&), rather than add_entry(Meow&&), because the latter takes Meow as a "sink" argument, which takes ownership and potentially leaves it in a a moved-from state:

Meow m;
other_function(add_something(std::move(m)); // m is now in moved-from state

I think that something like with_debug_entry might better communicate the intended fluent-style API. so we could have

void add_debug_entry(ProtoStruct&);
ProtoStruct with_debug_entry(ProtoStruct&&);

void f()
{
  ProtoStruct s1{{"cat", "meow"}};
  add_debug_entry(s1);
  component.doCommand(s1);

  component.doCommand(withDebugEntry(ProtoStruct{{"dog", "woof"}}));
}

And then I think with could be implemented in terms of add

[stuqdog]

@lia-viam ooh yeah I like that change, thanks! just added :)

[lia-viam]

I think now that add_debug_entry is void this will need a change, maybe you can change the get_pose call below to be

pose_in_frame pose = client.get_pose(fake_component_name(), destination_frame, {}, with_debug_entry(fake_map(), debug_key));

and the above line deleted, then technically we'll be testing both the add and move version.

Other than that LGTM though, and feel free to merge without re-requesting review once the build passes