Improve the agent protocol

Current situation

The 'agent' protocol (aka how an agent interact with the agentchannel service) uses three events:

• {'kind': 'exec', 'command': script_command}
• {'kind': 'put', 'path': script_path, 'file_id': script_uuid, 'root': ''}
• {'kind': 'get', 'path': remote_path, 'file_id': file_uuid}

The exec command almost always refer to a script transmitted by a put command.

Desired outcome

Scripts are often small. If the script is small, we should join the put and exec commands in a new run command:

• {'kind': 'run', 'filename': script_path, 'content': script_content, 'command': script_command}

It's a new command, and new agents will be able to use it. They still support the previous way, to handle backward compatibility, and to be efficient if the script is big.

New agents provide a .metadata.version entry in their registration demand. If the version is 1.9 or higher, the arranger will produce the new commands whenever possible. If the entry is missing or smaller, the regular commands are produced.

In addition, the agentchannel service now serves up to 10 simultaneous incoming requests (waitress_threads_count, defaulting to 10, must be at least 4, can go higher).

Also, notifications are debounced (Thanks CGI for the patch!), preventing possible ghost channels in case of mass deregistrations of agents.

Finally, enriched the GET /agents endpoint. Registrations now have a status.phase entry in addition to the usual communicationCount & al. Its possible values are the usual IDLE, BUSY, and PENDING.