It is not clear why this would be a good thing to do. There are various reasons for this:

• No use case has been provided
• The database server is likely to be configured with a high limit for maximum connections that is beyond the capacity of MaxScale
• Within MaxScale, we do not know what other loads there may be on the database server, and therefore do not know that it is sensible to allow MaxScale to run up to the server limit; we cannot assume that MaxScale is the only client for the database server
• Running right up to the limit is bad because once the limit is reached, no further connections can be made, meaning that a root user cannot get in to the server to exercise control or deal with a problem
• It is architecturally awkward to do. This could be overcome, but there do not seem to be enough reasons to justify such work. Without significant changes, the error received by the user would be that the session could not be established (which also has a number of other possible causes).
• The user who writes the configuration file is in a better position to judge what limits to put on MaxScale connections than an automatic process
• Limitation of connections is being provided on the client side, on a per service basis, and this seems the logical point at which to constrain connections
• SFAIK there is no client who wants this badly enough to pay for it.

Use-case missing.

Not clear why MaxScale should do this.