Enable key chaining to protect super/sub namespaces

[jhiemstrawisc]

Another tool for admins, this PR allows a registry to be run such that it requires key chaining to register a sub/super namespace of an already-registered namespace. For example, if /foo/bar is registered, when key chaining is enabled, neither /foo nor /foo/bar/baz can be registered unless by a key paired with /foo/bar. Another example -- if /foo and /foo/bar are both registered, then we cannot register /foo/bar/baz unless the key is also registered to one of the superspace set (/foo and /foo/bar.

I think eventually we should enable these types of registrations via tokens as well -- if I own /foo and I want to enable Emma to register /foo/bar, I should be able to generate a token with the key registered to /foo to enable any public key Emma wants to use. Based on feedback to this PR, I'll open that as an issue for future development.

[jhiemstrawisc]

Closes issue #333

[jhiemstrawisc]

Notes on testing:

1. Build and fire up a registry. Then launch an origin with a namespace like /foo/bar ensuring that the origin is pointed at your local registry. Double check that the namespace is saved in the sqlite database. Once confirmed, terminate the origin.
2. If running as root, delete /etc/pelican/certificates/* and /etc/pelican/issuer.jwk. Adjust accordingly for non-rootly execution.
3. Run a new origin, this time with a namespace that either prefixes or suffixes /foo/bar. For example, you could do /foo or /foo/bar/baz. Because you deleted the origin's registration key in the previous step, the origin will generate a new key and attempt to register it. Registration should fail at the origin with a periodic ERROR message that explains why registration fails. The registry should report a WARNING with similar information.
4. Now re-do this whole shebang, but add Registry.RequireKeyChaining: false to your pelican config. This should turn the feature off and allow registration under different keys.

[turetske]

LGTM!