skywire-visor expose DMSGHTTP server

[0pcom]

• visor will expose a dmsghttp server that exposes a simple file system over dmsghttp to authorized clients (see authorization mechanism for inter-service communication via whitelisted PubKeys; for simplicity, it can be same public key as setup node or can be separate key)

  • root of the dmsghttp file server will be the ./local/logs directory

• server will support GET request in the following form for log retrieval

  # GET index of available log files
  GET /
  
  # GET specific log file
  GET /2022-09-04.csv 

• server will additionally support the following calls to manage the reward

• in order to configure the logging server appropriately, the hypervisor API needs to support two new endpoints

  • GET /visors/{pubkey}/log/rotation
    • call retrieves the log rotation interval
  • PUT /visors/{pubkey}/log/rotation
    • call accepts request body that has json encoded values to be set in skywire-config.json for the log rotation interval
    • this requires a new field to be added to the skywire-config.json with the name log_rotation_interval
  • GET /visors/{pubkey}/rewards/address
    • fetches reward address set for visor if any

[0pcom]

We will need a new field in the config to specify log rotation interval.

If we want to serve other logs as well; the root of the dmsghttp server needs to be the local folder itself.

fetching just the rewards address via the api from the hypervisor as specified is redundant, the functionality for setting and getting values which are set in the privacy config is now in my PR. Just need to add the hypervisor api endpoints.

we need to serve sortof an index of files which are being served by the logserver as well as the hash or checksum of these files

DMSGHTTP Log Server conflicts with the visor

the dmsghttp logserver is now integrated with my PR #1369

it does not function as intended yet.

if one starts a dmsghttp server and then starts a visor, dmsgget will fail to fetch anything from the dmsghttp server.

if started in the reverse order, dmsgget can work.

there are no errors generated on either the visor or the dmsghttp server. I assume they are competeing for or consuming the same resource.

---

the current error with my implementation of dmsghttp logserver into the visor is "request has no associated listener" - which occurs on dmsgget requests for files which exist.