Define a security model for accessing user profiles and user profile data

[azasypkin]

Summary

Up until recently, we had a single consumer of the user profiles and user profile data - Case assignments. Due to limited demand and a well-defined scope of usage, we didn't bother to define a strict and comprehensive security model around user profiles. The solution we came up with was to gate access to user profiles and their data behind other features. For example, if a user has Read access to the Cases application, they will automatically be granted privileges to search through user profiles and see some of their data (such as avatars). This relationship was based on the access tags applied to the API endpoints used to retrieve profiles ([1], [2], [3]).

Today, however, we see that user profiles are being adapted more and more across platforms (e.g., created_by as the top-level field for all Saved Objects) and solutions, which makes it harder to enforce required access with API tags alone. Moreover, we might need to differentiate access between public (e.g., avatar) and private (e.g., encrypted or sensitive user preferences or settings) user data.

In the scope of this issue, we need to define who can access what, and what mechanisms we'll provide to consumers to enforce proper access to user profiles and user profile data.

[1] access:bulkGetUserProfiles tag applied to the API route

https://github.com/elastic/kibana/blob/be3f66fd45db4001b9437281a2cb075e817fa25f/x-pack/plugins/security/server/routes/user_profile/bulk_get.ts#L27

[2] bulkGetUserProfiles tag added to a Cases feature

https://github.com/elastic/kibana/blob/be3f66fd45db4001b9437281a2cb075e817fa25f/x-pack/plugins/cases/common/utils/api_tags.ts#L31

[3] bulkGetUserProfiles tag added to a Dashboard feature

https://github.com/elastic/kibana/blob/70813bac5a986c5839b577e18d9b4a7965901474/x-pack/plugins/features/server/oss_features.ts#L212

### Tasks
- [ ] [Question] Is user profile ID a sensitive piece of information?
- [ ] [Question] Should anyone be able to resolve user profile ID to user profile (excluding data)?
- [ ] [Question] What would be a minimum set of profile fields (e.g., full name, email, last login date, security realm) we could safely expose to other users?
- [ ] [Question] Should we treat bulk resolve (`_bulk_get`) the same as resolving a single user profile ID?
- [ ] [Question] What user profile data can be public (e.g, avatar picture) and what should be accessible only to owners and admins (e.g., preferences)? How to separate this data clearly?
- [ ] [Question] How can we _safely_ expose profile search/suggestion API? How can we enforce current-space-only requirement automatically (configurable?) and still allow consumers to specific additional privilege requirements on both client and server side?
- [ ] [Question] How can we come up with the model that won't require any breaking changes once we support user profile management capabilities for administrators?

[elasticmachine]

Pinging @elastic/kibana-security (Team:Security)