Store/access beacon LightClientBootstraps by neighborhood

[kdeme]

Current Portal beacon specifications state that all types are stored for the full range by all nodes (potentially).
Requests and gossip happen in a random way and not by targeting closest to content id.

This is fine for the latest finality and optimistic update (only is 1 for each).
It is also fine for the LightClientUpdate:
LightClientUpdate size * MIN_EPOCHS_FOR_BLOCK_REQUESTS / 256 = ~3.5MB

But for the LightClientBootstrap the total storage is too large to be negligible:
LightClientBootstrap size * MIN_EPOCHS_FOR_BLOCK_REQUESTS = ~850MB

As this type has only individual access, and the content key is by hash, I think it would work fine to store this type based on its content id.
So for this only this type in the Portal beacon network a NH gossip and RFContent would be done. The others would still use the random versions.