List actor definitions for workspace

[git-phu]

What

Part of #9652
Tech Spec

Implements routes to list all actor definitions a given workspace is configured to use. Depends on #11305

Recommended reading order

Easiest to view by commit

User Impact

Doesn't change the behavior of existing routes

[pmossman]

Looks good to me! Left a non-blocking suggestion about handling MockData

[pmossman]

hmm, I'm trying to think if there's a more elegant/dependable way to set up the public/custom mock data more clearly. Instead of relying on the right definition being at index 3 here, I wonder if we could basically define them as public static fields of MockData.java so we could access them in tests by doing something like

final StandardSourceDefinition customDefinition = MockData.CUSTOM_SOURCE_DEFINITION;

instead of

final StandardSourceDefinition customDefinition = MockData.standardSourceDefinitions().get(3);

Would need a little bit of rearrangement within MockData.java but might be worth it? Like instead of defining each of the four SourceDefinitions inside the standardSourceDefinitions() method, you'd define them as public static fields and then update that method to just return something like:

return Arrays.asList(SOURCE_DEFINITION_PUBLIC_CATALOG, SOURCE_DEFINITION_PRIVATE_CATALOG, SOURCE_DEFINITION_PRIVATE_CUSTOM);

Or something like that.. there might be a better way that isn't occurring to me right now.

This might be more trouble than it's worth. At the very least, it might make sense to just add something to MockData.java like:

public SourceDefinition getPrivateCustomSourceDefinition() {
    return standardSourceDefinitions().get(3);
}

so that at least we don't need to externally rely on the third index as a magic number

[git-phu]

yup, great idea!
I think I like the idea of making each mock object a public static field but maybe we didn't want the class instantiation to be creating so many objects?
I'll go with creating a descriptively named getter method for each mock.

[pmossman]

I was trying to think through what would happen if a definition was somehow in both of these lists, like in a situation where a public: false definition later became public: true. But then I realized you're already filtering out public: true definitions in the granted query, so I think we're covered there!

[git-phu]

oh right exactly! I asked about whether we should clean up old grants when I first thought of this too, but for now I think filtering out public in the granted query should be fine.