[Persistence] Cache ids of bootstraps

Bootstrap components are used to inform specific
policies for mutating components. Because
databasePersistence uses some custom SQL to
identify bootstrap components, the component
cache is effectively circumvented, meaning that
every time bootstrap components are looked at a
database interaction occurs. This has bad
latency implications when triggered from policy,
particularly where database latency is high,
and has been identified as a contributing factor
to nasa/mct#111.

This change caches the list of component IDs
found to be bootstrap components on first
invocation, and looks up via those IDs
subsequently. Looking up by ID does use the
component cache, thus avoiding the extra cost of
database access while still remaining at least
as up-to-date as the component cache itself.
[Inspector] Avoid creating extra Info View

Previously, Inspector created a redundant version
of the Info View, which doubled latency issues
observed in the instantiation of the Info View as
observed in nasa/mct#111. This change creates
the view only once on view change.
[Persistence] Add Step-Behind Cache

Introduces a 'Step-Behind Cache' to handle
custom queries. This returns values which are
effectively one step behind the results given
by the real operation being performed.

This is used to provide quick answers for
custom database lookups (such as getting
all users) while still receiving updates
eventually, without incurring the cost of
polling. This is useful in cases (such as
getting a list of users) where the data
changes infrequently, and where it is
acceptable to be somewhat out-of-step with
the ground truth.

This addresses the remaining known cause
of latency in nasa/mct#111.
[Persistence] Add doc, licenses

Add JavaDoc to StepBehindCache implemented as
part of fix for nasa/mct#111
[Persistence] Use StepBehindCache for bootstraps

This consolidates code around solutions for
nasa/mct#111
[Persistence] Test step-behind cache
[Persistence] Pre-initialize all-user cache

Load the all-user cache when the Persistence
Provider is first activated. This ensures
that when some user action needs to make use
of this cache it has some value to return;
otherwise, an actual database lookup will be
required to complete the request, which can
be time-consuming.
[Persistence] Use thread pool for step-behind cache

Use a thread pool in step-behind cache to avoid creating an
excessive number of background threads.

While the existing time delay provides some throttling
with regard to the number of actual look-ups initiated, it
is not a guarantee against rampant thread creation,
particularly where time delay is less than the time taken
to complete the underlying lookup operation.
Merge pull request #232 from VWoeltjen/mct111

[Persistence] Reduce lost responsiveness due to latency