The rate limit mechanism only protects the html web interface as it's tied to the 
LoginAction::handle() method.

Rate limiting should be pushed down to LoginAction::verifyLogin which is called by
determine_user() in the inner_main, handle_rest and handle_xmlrpc methods in client.py.

For this ticket, we will just reuse the existing client.db.config.WEB_LOGIN_ATTEMPTS_MIN
setting for all three http based password access methods. I see no reason to have different
number of attempts depending on the method.

With web login, we save logged in state as a session token. As a
result only one login is needed for access to multiple pages as long
as it is in the same session.

Since APIs are stateless, every access is a login. We have existing
mechanisms to rate limit calls to the API with valid credentials. So
this method should be invoked only with invalid credentials.

I should be able to pass an argument to verifyLogin that indicates
that I am looking for a stateful login (from the LoginAction). In this
case, calculate the rate limit and reject if exceeded.

If it is a non-stateful login, check the rate limiter and return
reject if exceeded.  if not exceeded, verify the password. If it
verifies, do not update the state of the limiter, otherwise increment
the rate limiter and save the state to the otks db. This should limit
incorrect guesses to a predefined rate and allow correct guesses
through.

Given good and bad passwords for the user U.

  t=0  bad
  t=5  bad
  t=10 bad
  t=15 bad
  
all further attempts up to t=60 are rejected.

  t=0  bad
  t=5  bad
  t=10 good
  t=15 good
  t=20 good

only 2 of the 4 have been used and all good attempts pass through.

I think this works. However the otks database will get even more
activity and it can't sustain a high rate of activity. Since most hits
for API's should not result in writes, maybe this will work. Will have
to test.

Completed in changeset:   7556:273c8c2b5042 on issue2551063.

A new pair of settings: api_failed_login_limit and api_failed_login_interval_in_sec
were added. These are shared across both API methods. It was not tied into
WEB_LOGIN_ATTEMPTS_MIN as WEB_LOGIN_ATTEMPTS_MIN is used manually and a longer wait
time on failed automaed API logins may be needed.