Move retrieval of visible blocks to a standalone service

Extracting that logic out into a separate service is a good idea in general. Whether the block storage is the right place is not clear for me.

I am also not 100% sure this should be on storage, but it might be okay. For now, just tweaking some things and fixing the tests.

I think this is a good abstraction, RTBC + 1 from me.

This feels much cleaner to me. We have a simple service that combines storage and access in a specific and needed method. It can be swapped out independently of the storage, and is actually then easier to test.

RTBC!!! - Very nice idea!

Does this still need further tests as stated in issue summary or is this ready?

Yes, it has tests now, and the old ones are restored.
I'd considering this RTBC, and I ran it by @EclipseGc

RTBC then

@dawehner pointed out that theme negotiator is being misused here.

Still RTBC

Oh, that returns an object instead of a string.

#10 covered the intent of my change, I just did it wrong, so setting back to RTBC.

Agree with RTBC

Reclassifying this as a bug since having the FullPageVariant directly accessing block and checking access is the presentation layer reaching through the business logic layer and directly into the storage layer. This is a bad idea and as the issue summary points out more efficient storages would have to replace the FullPageVariant.

This issue is a normal bug fix, and doesn't include any disruptive changes, so it is allowed per https://www.drupal.org/core/beta-changes. Also this change makes life easier for contrib and to improve the performance of loading blocks per region. Committed ec7b056 and pushed to 8.0.x. Thanks!