Bug 847014

master commit 396b48fde3613c359b49ca4b776ee18fa39f3865

Allow an unlimited number of children when expanding the tree node. Although
this may create a large vertical expansion, it may also be what the
user wants.  See BZ comments for more on the approach and alternatives
but basically, take this [easy] approach until it's clear that users, or UX,
want something else.

*** Bug 848851 has been marked as a duplicate of this bug. ***

master commit 30a6818e7ae101dc8df7edc198c5ee9ac790683e

We decided not to allow an unlimited number of child resources be returned
when expanding a node in the tree.  But there are major problems with
simply limiting the children to 200.  This is what we do today, and the
results are unordered. Meaning you can lose any number of resources of
any types and it is not possible to know what you are missing. And we don't
indicate that the tree is incomplete. If we add ordering (alphabetical by
resource name) you still lose any number of resources, but always the same
ones.  In this way it is much easier to realize that you are missing
child resources (and/or entire child types) because the resources returned
obviously stop as some lexigraphical point.

Still, we don't want to allow an unbounded fetch in the GUI.  The solution
here is to move the unbounded fetch to the server side and to introduce
SLSB support to prune the results and return the pruned child set.  In this
way we can limit the max child resources while returning a much more
reasonable resource set.

The way it works is as follows: There are two variable in use:

maxResources
Will not return more than this number of resources.  If the original fetch
exceeds maxResources then maxResourcesByType will be enforced.  If, after
trimming by type, maxResources is still exceeded, then the tail
resources (assuming a sorted set) will be removed to enforce the limit.
If <=0 the default (currently set to 1000) will be used.

maxResourcesByType
If maxResources is exceeded by the initial result set then members of each
type will be trimmed down to meet this limit.
If <=0 the default (currently set to 200) will be used.

The defaults may change after this check-in based on testing results. The
GUI will not set these values in the fetch, so the defaults will be applied.

The default values can be overriden (and applied to all fetches/sessions) by
setting the following system properties (in rhq-server.properties and restarting):
rhq.server.findResourcesByCriteriaBounded.maxResources
rhq.server.findResourcesByCriteriaBounded.maxResourcesByType

So, this allows us to:
- Avoid an unbounded fetch.
- Have any distribution of child resources of various types as long as the
  maxResources limit is not exceeded.
- Apply an even and understandable pruning when necessary.

It does not yet allow us to indicate in the tree which resource types have
been pruned.  This will be a future enhancement and tracked as
https://bugzilla.redhat.com/show_bug.cgi?id=848853.

Test Notes:

See the comments in bug 784571.

*** Bug 753141 has been marked as a duplicate of this bug. ***

Bulk closing of items that are on_qa and in old RHQ releases, which are out for a long time and where the issue has not been re-opened since.