Pass the user and request into BlockManager::getUserBlock

Pass the user and request into BlockManager::getUserBlock

Blocks are checked from the User object. Specifically,
User::getBlockedStatus instantiates a BlockManager and calls
BlockManager::getUserBlock. However, checking the block often depends
on knowing more about the state than the User should know. As a result,
the global user and request objects were passed into the block manager
on construction.

Whether the global request object should be passed into a service
constructor is still up for debate, so this moves the check for the
global state back to User::getBlockedStatus for now. (Note that it
reintroduces the problem of the User knowing more about state than it
should.)

This change also makes clearer the cases in which
BlockManager::getUserBlock is called from the User.

Different blocks may be sought, depending on the user and their
permissions. The user may be:
(1) The global user (and can be affected by IP blocks). The global
    request object is needed for checking the IP address, the XFF
    header and the cookies.
(2) The global user (and exempt from IP blocks). The global request
    object is needed for checking the cookies.
(3) Another user (not the global user). No request object is available
    or needed; just look for a block against the user account.

Cases #1 and #2 check whether the global user is blocked in practice;
the block may due to their user account being blocked or to an IP
address block or cookie block (or multiple of these). Case #3 simply
checks whether a user's account is blocked, and does not determine
whether the person using that account is affected in practice by any
IP address or cookie blocks.

Bug: T231919
Change-Id: I3f51fd3579514b83b567dfe20926df2f0930dc85