Selectors: promote ResourceOwners to Selector

[ryanfkeepers]

Issue

Corso design has deviated in path from original Selector design, and we're beginning to see idealogical collisions between the two. For example, in #1505 we want to transition backups to be split between resource owners (ie: moving from 1:many backup:owner towards 1:1).

Current selectors are designed for granular queries such as, "get all U1's mail, also U1 and U2's contacts". This places resource owner identification at a per-scope level, rather than a per-selector (ie: per-backup) level, causing each selector to produce a complicated venn-diagram of owner-data pairings. As Corso design has matured we've moved away from supporting granular and compound queries such as these. Therefore the current design is not only complicated to reason about, it's also more complication than Corso wants to support.

Proposal

Resource Owner identification is to be removed from the scope-level declarations. Instead, each Selector will recognize a single, canonical list of resource owners. IE:

// this current design
s := selectors.NewExchangeBackup()
s.Include(
  s.Mail(users, folders, mailIDs),
  s.Contacts(users, folders, contactIDs)
)

// will become
s := selectors.NewExchangeBackup(users)
s.Include(
  s.Mail(folders, mailIDs),
  s.Contacts(folders, contactIDs),
)

// The new selector struct would look like this:
type Selector struct {
	Service service
        resourceOwners filters.Filter
	Excludes []scope
	Filters []scope
	Includes []scope
}

All scopes in the selector would implicitly apply to each resource owner. Eg: if the resource owners contains [Alice, Bob], and the scopes include MailFolder(Inbox), then the selector can be interpreted as "select all mail in the inbox for alice and bob".

Usage Changes

Backup data aggregation currently employs the following pattern:

1. generate a selector
2. pass the selector to a Backup Operation
3. pass the selector to GraphConnector
4. for each scope in the selector's Included scopes
5. for each resourceOwner in the scope (or, as fallback, the tenant's owner list)
6. collect all data for backup as a single set
7. run the backup

In the proposed change the resource owner iteration would migrate above the operation creation. This would generate N backup operations, one for each resource owner.

1. generate a selector for a given set of resourceOwners (or, as fallback, the tenant's owner list)
2. for each owner in the selector.
3. pass the (owner, selector) pair to a Backup Operation
4. Pass the selector to GraphConnector
5. for each scope in the selector's Included scopes
6. collect all data for backup
7. run the backup

Additional Needs

To minimize cognitive load, and conflicts between intent and available data, it is not in our best interest to pass a (owner, selector) pair into operations or graph connector. Doing so provides downstream packages the option of abiding either the intended user, or the original user set in the selector. We can simplify the situation by identifying a singular resource owner within a selector instance, and passing only the selector into processes.

type Selector struct {
	Service service
        DiscreteOwner string
        resourceOwners filters.Filter
	Excludes []scope
	Filters []scope
	Includes []scope
}

Thus, the precondition for using selectors is that the caller first splits the selector along its owners with a func like below. This should produce a set of N selectors, one for each resource owner. Alternatively, the caller can set the DiscreteOwner value directly. If the selector uses a wildcard value for its user list such as selectors.Any(), the ownerList parameter is expected to provide a fallback list of distinct resource owners to iterate over instead.

func (s Selector) SplitOnOwners(ownerList) []Selector {...}

[ryanfkeepers]

Migration is complete.