More powerful API Configuration

[myxoh]

Addresses the feature request: #1883

Notes, because I did not want to introduce a name conflict in the user scope (i.e. someone else is very likely using the name configuration as a helper), I renamed the param to api_configuration, I'm open to a better naming if possible.

To read the PR and understand the changes: There's a certain complexity on distinguishing between the command running at pre-setup time (i.e when it's being parsed and stored on the main API for re-playing on mount time) and mount time. As such, I've introduced the LazyValue objects which remember how they were accessed, and know that they are lazy, therefore I can distinguish evaluated params from params that should only be evaluated at Mount-Time.

Because I was adding features to the configuration, I've decided to add 2 additional ones that seemed used, conditionally executing code based on a configuration (unfortunately a simple if block won't do on the main namespace as I cannot record the unevaluated value. i.e. I only know the response of the if statement, but I can never see that there was an if statement )

And arbitrary code on mount (that admitdly would take care of the conditional issue assuming you were happy to moving the code to that block).

Each part of this PR is open for discussion

[dblock]

This looks solid. Haven't done a thorough CR yet, but wanted to discuss naming, first.

If I am not mistaken we liberally confuse "api" and "endpoint", that is we mount endpoints but they are derived from Grape::API. I think we want to distinguish full APIs with endpoints, so should api_configuration be endpoint_configuration? But then Grape also has config. I wonder if we're better off standardizing on config for all configurations? I wouldn't worry about user conflict, I've seen a lot of APIs and I've never seen config or configuration in user scope. Another possibility would be just options, because we mount with: options and this seems like a good catch all. Thoughts?

I think on_mounted should be mounted, which is similar to included in Ruby.

Is there scope to mounted? Should it be receiving options such as the parent that is mounting the endpoint?

I think we could simplify conditional on: options[:enabled] as given options[:enabled], which would be similar to params which is more consistent. If we want to introduce more complex conditionals (don't see why rn) in the future we can always make given a wrapper of conditional on: .... WDYT?

[myxoh]

HI @dblock , updated with the new names. I agree mostly.
The only change to your suggestions is that I've kept configuration rather than options, problem with options is that it was conflicting with local parameters named options in too many places, making the change harder to implement in a sanely way

[dblock]

I'm merging this. 👏