[Epic] V3 API design

[andrewazores]

          I'm thinking the v3 API should actually have a Target model that has a jvmId, alias, labels and annotations, and:

• 1-to-1 relation to a DiscoveryNode (this places the Target in the discovery tree)
• 1-to-many relation to ActiveRecordings that this Target "owns"
• 1-to-many relation to ConnectionUrl, which may be JMX or Agent HTTP. When the server learns about a connection it's added to this table, and when a connection is opened and the JVM ID is computed then the relation between the Target with that JVM ID and this new URL is modelled.

This way, stored credentials can also be associated to a particular ConnectionUrl or set of ConnectionUrls rather than a whole Target, since if the Target actually exposes both JMX and Agent HTTP then it needs two different sets of credentials.

Then the API should require clients to specify Targets by ID, since a Target may have a null jvmId until a working ConnectionUrl is added for that Target.

Right now that doesn't make much sense for dealing with archived recordings because the Target records are deleted when a Target disappears, so any data we persisted using the Target's ID or jvmId or anything else becomes "orphaned" and we lose any of the other context we had about that Target. So I think there should also be a field in the Target record that reflects whether the Target is online/reachable, and this flag is simply updated when a target disappears rather than deleting the record. Then we can always look the record up again and have that full context about it to remain associated with its archived recordings.

Originally posted by @andrewazores in #62 (comment)

See also #71