Remove 'with sharing' from fflib_SObjectSelector and fflib_SObjectDomain

[yurybond]

There is a big inconsistency in definition of selector base class and trailhead documentation of how it shoud be used.

1. According to trailhead we need to avoid using of 'with/without sharing' on selectors to allow to apply calling context (for instance respect of controller's context when use selector method) See more:
   https://trailhead.salesforce.com/en/modules/apex_patterns_dsl/units/apex_patterns_dsl_learn_selector_l_principles

2. For some base class for all selector classes fflib_SObjectSelector has 'with sharing' which is inherited and applied to child class (in other words selector that inherit base class fflib_SObjectSelector will ignore caller 'sharing' context). See more
   https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_classes_keywords_sharing.htm

3. I am afraid removing of 'with sharing' keyword from base selector class and base domain class will affect a lot of people around the world, but we have to do it to make it work properly.

[jjulicher]

I totally agree with this.
Although with the latest update perhaps this should be inherited sharing?

[yurybond]

@jjulicher indeed! According to @afawcett recommendation I created a new base class with inherited sharing. Andrew's comment in on my pull request: #200

[wimvelzeboer]

I also agree that the base class should be set to inherited sharing so that the caller can decide how to use it.

It would be nice to use the following pattern that I also use for Service classes.

Application.cls

public with sharing class Application
{
    public static final fflib_Application.SelectorFactory Selector =
            new fflib_Application.SelectorFactory(
                    new Map<SObjectType, Type>
                    {
                            Account.SObjectType => AccountsSelectorImp.class
                    }
            );

    public static final fflib_Application.SelectorFactory ElevatedSelector =
                new fflib_Application.SelectorFactory(
                        new Map<SObjectType, Type>
                        {
                                Account.SObjectType => AccountsSelectorElevatedImp.class
                        }
                );
}

AccountsSelector.cls
This inherited sharing class contains all the selector methods.

public abstract inherited sharing class AccountsSelector extends sflib_SObjectSelector
{
    ...
    public AccountsSelector()
    {
        super();
    }
    public AccountsSelector(Boolean includeFieldSetFields, Boolean enforceCRUD, Boolean enforceFLS)
    {
        super(includeFieldSetFields,enforceCRUD,enforceFLS);
    }
    ...
    public List<Account> selectById(Set<Id> idSet)
    {
        return (List<Account>) selectSObjectsById(idSet);
    }
    ...
}

AccountsSelectorImp.cls
This is an empty class that is extended from the AccountsSelector and add the with sharing

public with sharing class AccountsSelectorImp extends AccountsSelector {}

AccountsSelectorElevatedImp.cls
This without sharing class only contains a constructor telling the framework to bypass CRUD and FLS checks.

public without sharing class AccountsSelectorElevatedImp extends AccountsSelector
{
    public AccountsSelector()
    {
        super(false, false, false);
    }
}

With this you can get a with or without sharing instance directly from the Application class.

[ImJohnMDaniel]

@daveespo, @afawcett, @yurybond, @wimvelzeboer, and @jjulicher -- With the introduction of PR #262, are we agreed that we can close this PR??

Any questions or concerns on this course of action?

[daveespo]

The subject of this ticket is about SObjectDomain and SObjectSelector however all of the talk and pull request is about SObjectSelector. Yes, #262 provides a viable workaround to the work proposed on this ticket so this ticket and its related pull request should be closed/wontfix

(there are some words I may want to say about SObjectDomain soon but I don't want to muddy up this ticket with those)