Add findPrincipalById helper

[XN137]

this simplifies frequent usage of the lower level loadEntity api (similar to the
existing findPrincipalByName helper)

[dimas-b]

Having this helper method in principle SGTM. However, given that PolarisMetaStoreManager is one of the main plugin / integrations points, I'm not sure about expanding its API surface with one more method.

[XN137]

why do you think its expanding the API surface?
its implementation is just reusing existing methods but encodes more information about the proper way to use them and about the type of entity they will return.
also simplifying code around "exception" handling.

these defaults methods probably never need to be re-implemented by actual classes.

[dimas-b]

It gives callers two options: 1) use the old method 2) use the helper methods... In my mind that expands the API.

I'm thinking that adding methods like this is probably an indication that we may need to rework the interface as a whole.

This is more of a point for thinking about, not an objection, really.

[dimas-b]

Code change LGTM 👍

Given that we already have other find* method in the metastore manager interface, this PR is probably fine to merge.

In general, I think we need to resume work on untangling different API concerns currently mixed in PolarisMetaStoreManager.

[XN137]

I think we need to resume work on untangling different API concerns currently mixed in PolarisMetaStoreManager

in what way is looking up a principal a different api concern in this case?

[dimas-b]

in what way is looking up a principal a different api concern in this case?

Principal is an Entity, but has dedicated access methods that are not applicable to other entities.

[flyrain]

Are we supposed to throw here? If yes, can we make the error message a bit more specific?
No value present --> Failed to find the principal by id: {}

[XN137]

ok i've added a commit to provide a more detailed error message.

however looking at the code in the beginning we do:

PrincipalEntity currentPrincipalEntity = getPrincipalByName(resolutionManifest, principalName);

which would fail hard if the principal did not exist.
and then in rotatePrincipalSecrets we are updating the principal behind currentPrincipalEntity.getId().

so we can be quite sure that another call to findPrincipalById will return a non-empty result.
only if someone externally was dropping the principal with precise timing could we hit this scenario and the old code would have resulted in an NPE in this case.

on that note, seems like all callers of rotatePrincipalSecrets are looking up the updated principal afterwards... makes me wonder whether the method should just return it directly (it loads it already internally).

[flyrain]

Thanks a lot for the change, @XN137 ! LGTM overall. Left one minor comments.