Add accessorID of token when ops are denied by ACL system

[mkcp]

Intended to resolve customer asks in #7010, plus wherever else I could find ACL debug logs with access to a token.

We employ a few different ways of getting the accessorID, depending on where we are in the agent.

• agent/local/state.go acquires it via internal RPC because local is a subcomponent of the agent and we don't have access to one. Adding an additional network hop in these service and check sync loops might be prohibitively expensive on a critical path, but I haven't profiled it. I would appreciate feedback on my impl here from folks w/ more Go and consul experience.

• Then various delegate and srv calls to ResolveIdentityFromToken so we can pull the accessorID off of it.

• Added some doc comments early on when I was still researching the problem. Can split into its own PR if needed.

And important note is that none of this is particularly tested, because I couldn't find any place that felt like it needed unit testing (could be wrong there) and integration testing logging felt... bizarre? I also had some difficulty building up a test case to induce the logs themselves so much of what I'm submitting here is taken on faith, the type checker, and a few thousand Test{Agent,ACL} runs to ensure I didn't break something important.

I would appreciate that whoever review this PR get about as nitpicky as possible. Treat this code like someone with 5 years of Go experience got a little {drunk/tired from a new baby/etc.} and rushed through this. I would like to learn as much as possible from whatever I missed. Thanks!

Will squash before merge.

[mkeeler]

Overall this looks great. I had handful of really minor comments or suggestions, as well as one slightly more important one about the new RPC and its usage in the agent local state.

Would it be possible to have tests for any of this? I have my doubts about whether it is feasible without major alterations to our logging and then whether its even desirable. Its probably not worth it but have you given it any consideration?

[mkcp]

@mkeeler I believe I hit all of your feedback!

Biggest change is that I extracted the code to grab the ident.ID() field and the accompanying requeset error handling up to an T.aclAccessorID fn that wraps when we call T.srv.ResolveIdentityFromToken or T.Delegate.ResolveIdentityFromToken with small changes depending on the context (a few endpoints & the agent/local/state.go).

There's a decent amount of copy-paste repetition in this approach, but it didn't feel like a complex enough operation to pull up to a utility package/repeatable helper fn. As a result of this change, the call sites for the logs are cleaned up significantly, getting a value to work directly and not having to fuss w/ errors/nil behaviors unrelated to logging the accessorID.

[mkeeler]

LGTM. This is going to make debugging ACL issues much easier.

[banks]

@pierresouchay you might like this :)

Great job @mkcp 🎉

[mkcp]

The last unaddressed item from review is: how do we test logs, and perhaps other telemetry-type functionality that's off core functionality but still providers user value.

My impression is that it seems a bit far off the critical path to warrant adding weight to the integration tests, and straightforward enough to see the results of that we'll hear back pretty fast from users if it's broken. And, given it's non-criticality, if it's broken it's not terribly destructive (e.g. dc downtime, lost business-critical records, etc.)

I'm going to squash and merge here this PR without testing it, but I'm willing to continue the discussion and follow up with tests if we decide to go that route.