Add EngineApiBoundary cop

[maxh]

This cop enforces modular isolation of Rails Engines. It allows engines to define an API surface in an internal api/ directory. Code outside the engine is only allowed to interact with the engine through that API surface. For more details, check out in the class comments in engine_api_boundary.rb.

Whereas Flexport/GlobalModelAccessFromEngine prevents an engine from reaching out into the global app/models, this cop prevents any code outside an engine from reaching in to access that engine.

A change in the main RuboCop repo is a prerequisite for this PR: "Allow cops to invalidate results cache" (rubocop/rubocop#7496).

[tleish]

Can I use this feature to prevent boundaries across multiple directories? For example, if a project included an engines directory (rails gems) and a gems directory (non-rails gems).

├── app
├── bin
├── config
├── engines <-- boundary
├── gems <-- boundary
├── lib
└── spec

As to why you may want to have both gems and engines seperated, see:
https://medium.com/@dan_manges/the-modular-monolith-rails-architecture-fb1023826fc4

Excited about this cop.

[maxh]

Can I use this feature to prevent boundaries across multiple directories?

Interesting. The directory tree of our codebase is similar, with top-level gems and engines directories. But we haven't seen a ton of boundary violation issues with gems -- only amongst engines. So our focus has been on engines.

This cop will prevent code in the gems from accessing code in engines. Indeed, it prevents any code outside the engine from accessing code in the engine.

It will not, however, prevent engines from directly accessing code in gems. Nor will it prevent either gems or engines from accessing "main app" models. To prevent engines from accessing "main app" models, you can use this cop: #5.

It may be possible to support both of these cops to support gems, or to create new gem-focused cops. Would you want to define an api/ surface to a gem?