METRON-1165 [FEATURE-BRANCH] Add ability for BundleSystem to add bundles after initialization

[ottobackwards]

As part of supporting parser extensions and the bundle system hosted in other applications than storm, and specifically for hosting in the rest service, we need the ability to add new bundles to the system, preferably without requiring an application restart or reloading the entire system.

The use case:

1. Install a parser extension assembly from the extension ui
2. switch to the sensor ui
3. create new instance (+) and be able to use the parser(s) from the assembly you just installed.

This PR lays down the ground work for that capability, and will be integrated with the extension ui branch if or when taken to the Feature Branch.

In this PR I further refactor the original NIFI Nar concept of Initial Context, which is used in the BundleClassLoaders and the ExtensionManager. I have moved the context to full classes, and moved their creation to those classes in a Builder implementation.

This allows the creation of multiple 'contexts' with different parameters and scopes.
I have also added the ability to merge one context into another.

Thus the idea is that:

• these classes have their initial context from the full scan of the bundle system library directories.
• adding a new bundle means on demand creation of a new context, for just that bundle
• we merge the bundles to make the new content available

The addXXXX capability is limited availability ( it is protected ).
It's only public facing exposure is through the BundleSystem class.

BundleSystem is the 'easy button', simplified interface to the bundles, and should be in most cases the only interface required. Exposing it this way allows us to be sure that the ADD calls are only called in a context where we can do the type of locking we want to do.

Testing

This is a preparation PR. The add functionality is not utilized outside the tests.
So this is a code review, no regressions check.

• Build and Tests should run

• Full Dev should start and have data in kibana ( no regression )

• Is there a JIRA ticket associated with this PR? If not one needs to be created at Metron Jira.

• Does your PR title start with METRON-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.

• Has your PR been rebased against the latest commit within the target branch (typically master)?

• [na] Have you included steps to reproduce the behavior or problem that is being changed or addressed?

• [na] Have you included steps or a guide to how the change may be verified and tested manually?

• Have you ensured that the full suite of tests and checks have been executed in the root metron

• Have you written or updated unit tests and or integration tests to verify your changes?

• [na] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?

• Have you verified the basic functionality of the build by building and running locally with Vagrant full-dev environment or the equivalent?

[ottobackwards]

@mattf-horton

[cestella]

+1 by inspection, this looks very interesting