fix: return null instead of false in case of invalid quota

[jvillafanez]

Prevent switching to a different server (in a multiple server setup) in case quota isn't set for a particular user.

Related to https://github.com/owncloud/enterprise/issues/7040

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[phil-davis]

There are some test fails for tests that seem to be better now.
For example, a test scenario linked to issue #49
https://drone.owncloud.com/owncloud/user_ldap/5351/29/13

  Scenario: authentication works when second of multiple configurations has an unreachable host configured # /var/www/owncloud/testrunner/apps/user_ldap/tests/acceptance/features/apiUserLDAP/serverConnection.feature:54

    Given a new LDAP config with the name "wrongLdapConfig" has been created                               # UserLdapGeneralContext::createNewLdapConfig()
    And LDAP config "wrongLdapConfig" has these settings:                                                  # UserLdapGeneralContext::ldapConfigHasTheseSettings()
...

    When user "Alice" requests "/index.php/apps/files" with "GET" using basic auth                         # AuthContext::userRequestsURLWithUsingBasicAuth()
    Then the HTTP status code should be "500"                                                              # FeatureContext::thenTheHTTPStatusCodeShouldBe()
      HTTP status code 200 is not the expected value 500
      Failed asserting that 200 matches expected '500'.

The test can be adjusted to expect the now good 200 status.

[jvillafanez]

But the "authentication works when first of multiple configurations has an unreachable host configured" responds with a 500 status. This seems inconsistent to me, and people will complain.
Right now, you need to have all the LDAP servers connected in order to log in. It might not be the best idea, but it works like that.

[phil-davis]

My point was just that the changed code in this PR has (somehow) changed the behavior of that test so that there is a 200 status rather than the previous 500 status. If that is a useful side-effect of the changed code then great, just change the test step to expect 200