Refactor TMail RateLimiting plan to be applied by domain

[Arsnael]

Today the RateLimiting plan on TMail is assigned individually to each user.

We should refactor that so we can change it to apply a plan to a domain (that will apply for every user belonging to that domain)

For this, we need to :

• change implementation of rate limiting in the api for managing binding plans to domains: RateLimitingPlanUserRepository -> RateLimitingPlanDomainRepository
• refactor so that each domain gets only one rateLimitingPlan instead of several
• modify EnforceRateLimitingPlan mailet to take into account the rate limiting plans on domains.
• change webadmin routes to manage domain plans: RateLimitPlanDomainRoutes
• guice bindings
• documentation

Attach a plan to a domain:

curl -XPUT http://ip:port/domains/{domain}/rate-limit-plans/{planName}

=> returns:
{"rateLimitPlanName": "XYZ"} 

Get list of domains belonging to a plan:

curl -XGET http://ip:port/rate-limit-plans/{planName}/domains

Get plan belonging to a domain:

curl -XGET http://ip:port/domains/{domain}/rate-limit-plans

Revoke plan of a domain:

curl -XDELETE http://ip:port/domains/{domain}/rate-limit-plans

DoD: unit tests + one integration test to show the routes are correctly bound to TMail

[Arsnael]

I'm not completely sure on this one so don't hesitate to discuss choices here

[chibenwa]

I'm not completely sure on this one so don't hesitate to discuss choices here

IMO one domain should only have a single rate limiting plan. It would make the job of the connector even easier (set the plan of the domain instread of add one, remove one).

Proposal:

curl -XPUT http://ip:port/domains/{domain}/rate-limit-plan

Returns:

{"rateLimitPlanName": "XYZ"}

WDYT?

[Arsnael]

You mean instead of adding first a plan, then binding it to a domain, there would be just one route that would add and bind it to the domain directly correct?

I'm ok with that.

Concerning then the rest:

• the update plan is not affected logically right? I use the update plan route but it's still bound to the domain
• however what about the delete? we still need a route to revoke the plan of a domain correct?

[chibenwa]

we still need a route to revoke the plan of a domain correct?

Yes.

[chibenwa]

curl -XPOST http://ip:port/domains/{domain}/rate-limit-plan

{
   "rateLimitingPlanName": "payingPlan"
}

• Refactor: user -> domain
• Refactor so that each domain gets only one rateLimitingPlan instead of several
• Also id -> Name is good.