The lack of handling to check whether the user was a dial-in user when answering akka-apps periodic member probes was making it use an arbitrary default (callerName) as the userId, explicitly violating the convention that dial-in/outs should have v_memberId userIds

That would botch whichever added janitorial tasks that operated upon akka-apps GetUsersStatusToVoiceConfSysMsg probes

 We need to increase the length of the voice conference. If we have lots of meetings running,
 there is a high chance of collision.

 Need corresponding changes to FreeSWITCH dialplan.

 In bbb_echo_test.xml, change to `expression="^echo(\d{5,11})$"`.

 In bbb_conference.xml, change to `expression="^(\d{5,11})$"`.

This reverts commit 37ed2c75, reversing
changes made to 5af41dab.

 - clean up
 - bind to port 8900

 - bind only to localhost

 The /healthz returns information is we are able to send and receive message to/from freeswitch.
 The /status returns information about freeswitch version and uptime.

 Currently, we user DTMF to inform the client when the call session is in echo test and when entering the voice conference.
 Unfortunately, sometimes when FS sends the DTMF, FS crashes.

 Monitor the progress of the call session using ESL events and propagate to the client.

 The client would be informed of these call states: CALL_STARTED, IN_ECHO_TEST, IN_CONFERENCE, CALL_ENDED.

 - When waiting for a response from FS after sending an ESL command and the ESL connection disconnects,
   the sending thread will be blocked as the trigger for it to unblock is the response from FS which never
   comes.

   Add a 30 second timesout waiting for response and give up to go send a new FS ESL command.

 - We want to be able to correlate client webrtc calls with freeswitch logs. We add extra info
   on callerid which we strip out in akka-fsesl.

 - poll FreeSWITCH for status of user so that akka-apps would be in sync with FreeSWITCH

 - We had an issue where FreeSWITCH, for some unknow reason, stopped recording the voice conference
   in the middle of the meeting while there are users in the voice conference. We've relied on the
   voice conf started event to trigger recording of wav files. This event is sent when the first user
   joins the voice conference. In this case, there was no voice user joined after the recording stopped
   as there were already users in the voice conference. TO make sure that the audio is recorded, akka-apps
   will send a "check if voice conf is running and recording" message to FreeSWITCH every 30sec. If akka-apps
   receives a "running=true recording=false" response from FreeSWITCH, akka-apps will send a start recording
   msg to FreeSWITCH.

 - when meeting ends, we try to eject all users by force from freeswitch to make sure
   that recording ends. However, we are not actually sending the command to freeswitch.
   This change sends the command so that users can be kicked out.

 - on auto-reconnect when FS restarts, the auto-reconnect add another
   listener to the ESL client resulting in multiple handlers of ESL events
   and multiple messages to akka-apps. This resulted in multiple recordings
   of audio when the first user joins as akka-apps receives 2 user join events.

 - Sometimes ejecting voice conf users using "conference vconf kick all" doesn't work. We need to
   forcefully eject the user by using "uuid_kill uuid".

 - add more logs to trace messages
 - add FS status check by sending ESL message to FS

 - FreeSWITCH core dumped and akka-fsesl managed to reconnect. However, commands (mute, unmute, record, etc.) to FS are not reaching FS.
   But events (user joined, left, talking) from FS are received by akka-fsesl. Can't determine where the commands are falling off. These
   extra logging hopefully helps us narrow down if this happens again.

   I wasn't able to reproduce the issue when stopping and restarting FS. Akka-fsesl reconnects and command/events are flowing in both
   directions.

   This will help us hunt an issue where a channel gets stuck in a voice conference.