Scope:
This issue assumes the work in MDL-63280 is complete so we have conversations linked to course groups (the ability to do so). This issue can proceed without the group-linking work.

• Update the backend APIs for messaging search as follows (We ONLY want to update search_* functions - so things like search_contacts and search_messages. The get_ functions are different and should have been handled in MDL-63280):
  • Results should reflect the 'site-wide messaging' admin setting .
    • If site-wide is disabled, results restricted to only those users sharing courses with the current user.
    • If site-wide is enabled, results show any users
    • FOLLOW UP MDL: Limit users returned based on user visibility in the site/course.
  • Users included, regardless of personal messaging privacy settings - this only comes into play when we want to initiate a conversation (or contact request) with someone - so we don't need to factor it in to search criteria, thankfully.
  • Should be able to search for:
    • Users who I don't have a conversation with (match user's first / last name / any existing fields we match on already), returning user
    • Names of users who I do have a conversation with (match user's first / last name), returning messages the user sent
    • Contents of messages in conversations I'm a part of, returning messages 
  • When returning users, inclusion of relevant information about the person
    • whether a contact or not (may already be present - need to check)
  • When returning messages, Inclusion of relevant information relating to the message
    • conversation details:
      • course name (if applicable) - depending on how MDL-63280 has been implemented, there may be a generic way to get 'relevant details' of what a conversation has been linked to - check there first!!
      • group name (if applicable)  - depending on how MDL-63280 has been implemented, there may be a generic way to get 'relevant details' of what a conversation has been linked to - check there first!!
      • Is the conversation a favourite? (Blocked by MDL-63213 for now) We don't need to show this.
    • Name of the user who created the message
    • Message time
  • We need to allow filtering by conversation, to facilitate searching for messages within a conversation. See MDL-63681 for conversation searching.
• We also  need to create a new web service aggregating the above search methods into a single call which can be made by the front end. Let's focus on getting the required information in the existing service first, before we worry about this. The current prototype UI works with the existing services, but just needs some additional information.
• Web service implementation should make considerations for lazy loading / batching.
• Deprecation of old search search APIs and web services, where no longer applicable. 

This issue has a wide scope, so may be better split into several smaller issues.