Avoid multiple mount pollution

[alexanderadam]

Soooo, I might have missed something here but the way I see this is, that PR #1893 introduced the behaviour seen in #2576.

And the problem to be tackled was different than what was implemented.
According to the Rack Spec, a Rack app only needs to be

a Ruby object that responds to call. It takes exactly one argument, the environment (representing an HTTP request) and returns a non-frozen Array of exactly three elements: the status, the headers, and the body (representing an HTTP response).

Therefore having Grape::API.call delegating to base_instance.call should be enough.

Howeveeeeeer, when using Rack::Test with def app returning a Grape::API class directly (e.g., API::V1::Ping), tests would naturally fail with 404.

So to me this looks like the fix with d29eb79 was a bit weird and introduced that bug in #2576. 🤔

But I could also be totally wrong with my understanding here.
And I'm therefore open to any corrections and learnings.

PS: I'm looking for a new adventure in case anybody is looking to hire or work with a Ruby/Rails/Crystal dev
PPS: would you be so kind and add the hacktoberfest-accepted label to this issue in case you find that PR helpful? 🥺

[dblock]

@alexanderadam Thanks! Fix CI/CHANGELOG and I'll take a close look - @ericproulx wdyt?

[alexanderadam]

@alexanderadam Thanks! Fix CI/CHANGELOG

done 🙂

[dblock]

This looks correct to me. Let's ask @bogdan and @myxoh to also look at this as they authored the linked issues/PRs.

[bogdan]

That's fine to me if it fixes the issue. The test looks perfectly right.

[ericproulx]

Looks good to me 👍 thank you

[ericproulx]

@alexanderadam could you mount your api multiple times and try with a configuration.

[dblock]

@alexanderadam see my comment on breaking up specs, too, please.