Add HttpInterface methods and add up-casts for type safety

[Vinai]

This PR does not add any functionality. Its only purpose is to make the usage of the HttpInterface response more type safe.
As far as I can tell there should be no backward incompatible changes, except for the HTTP related methods from \Magento\Framework\Controller\AbstractResult being moved into a new \Magento\Framework\Controller\AbstractHttpResult child class.

All core classes extending AbstractResult but referencing HTTP methods now extend the new AbstractHttpResult. Any non-web result type can still extend AbstractResult without having applyHttpHeaders() caled during rendering.

Please reference issue #3737 for further information.

[adragus-inviqa]

@Vinai - Are we sure we want a backwards incompatible change yet again? Why is this practice encouraged?

[Vinai]

@adragus-inviqa I see your point. I for one still think the platform could use more cleanup. It may be a bit OCB, but every time I see classes depending on an interface, but calling methods on a concrete implementation that are not part of that interface, it just strokes me the wrong way.
So I would like to see more small steps in the direction of a "cleaner" code base. I mean, what is the alternative? Keep everything as it is? Better to make use of semver and keep things moving IMHO.

Question: Have you used custom result types that relied on AbstractResult setting HTTP specific properties? Otherwise there should be no BC break.

That said, the changes to the AbstractResult could be taken out of this PR again of course. It would be a pity, but better then nothing I guess.

[adragus-inviqa]

I was half-venting, as the amount of BC-breaks in M2 is ridiculous. And BCs are not only about refactoring and clean code - it's about trust (actual, human trust), as I'm sure you know. And, in its current state, it's low. Sea-level-low.

Unfortunately, I see no way around some of the issues in here.

Maybe things are going to slow down in terms of BC in the future, but until then, I'm mentally working on Magento 13.46.

[Vinai]

I do hope things will get (a lot) more stable in time.
I'm genuinely curious: do you think the current status quo should be already kept as it is with the goal of preserving BC? Is it "good enough" for that already, or does it need further work until it should be allowed to stabilize? I would really like to hear your opinion.

[adragus-inviqa]

BiC = backwards-incompatible change

I hate BiCs during one major version, period.
"Good enough" was already decided for us, when Magento got out of alpha, right?
That's the thing the rubs me the wrong way: we shouldn't be talking about BiCs at this point at all.

But when M2 goes from app/code to Composer packages during a beta, people start thinking it's normal.

I do think the codebase needs quite a bit of refactoring, but I don't know how to do that without breaking my own rule (to not create any more BiCs). So I think it boils down to the amount of people impacted.

[Vinai]

Thanks @adragus-inviqa. I also agree that Beta was just like Dev.

[antonkril]

This is breaking change

[Vinai]

Removed the most BC breaking part of the PR, @antonkril

[paliarush]

Internal ticket created: MAGETWO-52571

[paliarush]

1. Please add/fix description for all new methods in the interface. E.g. here it does not make sense to split lines 23 and 24
2. Please change description of these methods in implementing classes to {@inheritdoc}

[Vinai]

Done.

[Vinai]

Thank you for your review. I've applied the changes you suggested or replied to your comments in 2 cases.

[antonkril]

While Result/Response API still requires bigger rethinking, this PR looks like the best we can do now from prospective of price (breaking changes)/value comparison.

[Vinai]

Rebased onto develop HEAD and resolved merge conflicts.