Re-organize /network, /network_info, /node/ids, /primary, /primary_info

[letmaik]

The network-related endpoints seem a bit random in their structure.

As a user I would have expected a hierarchical structure like:

• /network
  • general network info without node details, maybe just node count

  • { "service_status": "OPENING|OPEN|WAITING_FOR_RECOVERY_SHARES",
      "current_view": 123,
      "primary_id": 456
    }

• /network/nodes
  • collection of nodes
  • the primary node has an extra field "primary": true
  • optional filtering by public host/port: ?host=abc&port=444

  • { "nodes": [ .. ] } // list of /network/nodes/{id}

• /network/nodes/{id}

  • { "node_id": "...",
      "status": "PENDING|TRUSTED|RETIRED",
      "host": "...", // public host
      "port": "...", // public port
      "rpc_host": "...", // internal host
      "rpc_port": "...", // internal port
      "primary": true // optional
     }

• /network/nodes/self
  • 307 Temporary Redirect
  • Location: /network/nodes/123
• /network/nodes/primary
  • 307 Temporary Redirect
  • Location: /network/nodes/456
  • Note: This is not a redirect to the remote node's endpoint.

While doing this, I would unify the response data models for nodes and not have different ones for non-primary and primary.

NOTE: is_primary (status code based) is still needed!

[letmaik]

@eddyashton Would the URL scheme above work? There is an overload of /network/nodes/{id} and /network/nodes/self / /network/nodes/primary which in practice would be fine but I'm not sure if CCF has extra restrictions on that.

[eddyashton]

@letmaik These overloads should work correctly - in EndpointRegistry::find_endpoint(), we first look for an exact match if it exists (which will find /nodes/self and /nodes/primary), and only look for a templated match (/nodes/{id}) if we don't have an exact match. I don't think we have anything testing this currently, but it should work.