Use AccountProxyInterface instead of AccountInterface

Going to mark it but not sure if changing the constructor will be an issue or not. We will see!

The issue summary doesn't specify a reason for that change.

In my opinion it is desirable to specify the most narrow type for arguments and return values. AccountProxyInterface inherits from AccountInterface, hence it is wider. The AccountProxyInterface only should be used in places where the additional methods (setAccount(), etc.) actually get called. It follows that the AccountInterface is actually the correct type hint for controllers and access checks.

The Drupal class uses AccountProxyInterface for currentUser() but the other code I looked at uses AccountInterface. The default current_user service returns an AccountProxyInterface implementation.

In Java, you'd probably want to use AccountProxyInterface as the type hint because if you used AccountInterface but wanted to use one of the AccountProxyInterface you'd need to do a cast (preferably after testing that the object implements AccountProxyInterface).

Is there a reason why the current_user service can't be assumed to implement AccountProxyInterface?

When reasoning about which type to choose for a dependency, I suggest to always look at the problem from the consumers view point: E.g., if you implement an access check, or a controller, or some cache context, you choose an interface for your dependency which narrowly matches the requirements of your implementation.

There is no reason why any controller should type hint against AccountProxyInterface, since controller code only use the AccountInterface part of the current_user service.

As for Drupal::currentUser(): Unfortunately there is still procedural code (e.g., in core/authorize.php) which relies on methods of the AccountProxyInterface.

In Java, the current setup would be a bad design.

Apparently the current_user service is generally assumed to be AccountInterface, except for some code which expects AccountProxyInterface. The best solution might be to create two services, one for each interface. They could be implemented using the same Drupal\Core\Session\AccountProxy class. Then, change the code that expects AccountProxyInterface to use that service.

https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Session%2...
It is generally more useful to use \Drupal\Core\Session\AccountInterface unless one specifically needs the proxying features of this interface.

#10 sounds reasonable - i.e. try to limit AccountProxyInterface to only the spots it's actually needed and remove the concept from everywhere else.

There's broader issues

- UserSession should gone after 📌 Load user entity in Cookie AuthenticationProvider instead of using manual queries Needs work
- AccountInterface could be moved 📌 Move AccountInterface out of Session namespace Needs work