Support life cycle management of YANG file at runtime

Life cycle management of YANG file can start with add and delete only.

Here is what I envison:

Use case would be to have external system able to

  1. manage YANG model(s) that are self contained, e.g. there is no interaction with other deployed YANGs
    - add:
      action: RPC to either accept a file, or a raw string
      behaviour: That RPC would
                                validate the YANG file(s)
                                generate RESTCONF APIs to interact with it
    - delete
      action: RPC to delete based on module name and revision date (assuming this combinaison is unique)
      behaviour: That RPC would
                                delete the datastore owned by that YANG (config and oper)
                                unsubscribe all open web-socket subscribtion(s) to any path of that YANG tree
                                unsubscribe all open YANG notification subscriptions
                                remove the generated RESTCONF APIs along with the YANG file(s)

  2. Interact with specific YANG tree using the generated RESTCONF APIs of that YANG, for config and/or oper based on use case

  3. Register to web-socket notification for a specific path/sub-path of a YANG, or use TSDR for consumption of YANG notification (e.g. through kafka)

The web-socket / YANG notification thing can be seen as enhancements.