Allow to have multiple eradius clients bound to different interfaces about eradius HOT 3 OPEN

This is actually a symptom of much larger issue.

eradius was originally a standalone RADIUS server. Many of changes we have made to it have pushed it more into the direction of being a RADIUS library. I think we approaching the point where we should a complete refactor, drop everything that makes it a standalone server/client/proxy and make it into a library that can be used to implement a RADIUS function (client/server/proxy).

It's API should be similar to the diameter app.

Without the standalone functionality, the need of configuration of eradius through the application environment goes away. Everything that is needed to use a RADIUS function will be passed into the application as parameters and options.

from eradius.

@RoadRunnr we need a roadmap ;) Something like:

1. Draft the client and server API.
2. Add ability to configure radius servers via API without application environments
3. Allow having multiple eradius clients bound to different interfaces (according to the drafted API)
   ....

from eradius.

@RoadRunnr, @0xAX, @fholzhauser what if we will try split eradius:

• eradius - library
• eradius_prometheus_collector - implementation of server application based on library
• eradius_server - implementation of server application based on library
• eradius_client - implementation of client application based on library
  this way we can try to save all the work that was done in the current application and divide it into separate applications and a library. Also for backward compatibility we can keep the version 2.X.X with support and the new implementation will start from version 3.X.X where we can start use maps as described #111 etc.

from eradius.