Reporting custom logo does not work without direct access to .kibana index

[legrego]

Kibana version: 6.5.0

Describe the bug:
Users without direct access to the .kibana index do not see the custom reporting logo. Instead, these users are falling back to the default reporting logo.

Root cause:
We retrieve the custom logo using the UI Settings service, which requires an instance of the Saved Objects Client. When constructing the Saved Objects Client, the security wrapper checks to see if the RBAC authorization mode should be used, or if the legacy authorization mode should be used. This check relies on the auth mode being initialized.

Since the "request" used to retrieve the custom logo is fake, it never has a chance to initialize, so the authorization mode is always set to legacy. Since the user does not have direct access to the .kibana index, the legacy auth fails when we try to retrieve the custom logo.

Steps to reproduce:

1. Create a space, and assign a custom pdf logo in that space's advanced settings.
2. Create role with access to the space created in step 1. Do not grant access to the .kibana index.
3. Create user, and assign role created in step 2 along with the reporting_user role.
4. Login as this user, and generate a PDF report

Expected behavior:
The generated report should include the custom logo created in step 1 above, instead of the default pdf logo.

Any additional context:
Reported via https://discuss.elastic.co/t/x-pack-kibana-user-role-conflicting-with-spaces-permissions/159676

[elasticmachine]

Pinging @elastic/kibana-security

[legrego]

Note: a similar problem happens with CSV reports as well -- custom values for csv:quoteValues and csv:separator are not respected without direct access to the .kibana index.

[legrego]

Fix will be available starting with v6.5.4