mtl-2.3 compatibility

[ysangkok]

Before this PR, compilation on mtl-2.3 fails with

src/Amazonka/Error.hs:98:51: error:
    • No instance for (Alternative (Either String))
        arising from a use of ‘<|>’
    • In the third argument of ‘either’, namely
        ‘(h .# hAMZRequestId <|> h .# hAMZNRequestId)’
      In the expression:
        either
          (const Nothing) Just (h .# hAMZRequestId <|> h .# hAMZNRequestId)
      In an equation for ‘getRequestId’:
          getRequestId h
            = either
                (const Nothing) Just (h .# hAMZRequestId <|> h .# hAMZNRequestId)
   |
98 |   either (const Nothing) Just (h .# hAMZRequestId <|> h .# hAMZNRequestId)

The instance Alternative (Either String) makes little sense to me since I don't know how the instance can manufacture an empty value for the Alternative instance.

So in this PR, I try to avoid this instance.

This is untested, I'd appreciate advice on how best to test this.

[endgame]

Thanks for this. I have some requests, beyond the inline comments:

• Please add mtl >=2.2 && <2.4 to the bounds on amazonka-core.cabal.
• Please add an entry to lib/amazonka/CHANGELOG.md, which represents the project as a whole.

As for testing, the best thing I can think of is to build some packages (or maybe some of the example programs) with --constraint 'mtl >=2.3' and see if it looks good.

[endgame]

I have another request. How goes your plans to test this?

[ysangkok]

Testing is going well, cabal test --constraint='mtl>=2.3' is passing with no issues. And I can build the examples.

[endgame]

I am happy with this. Ping me when you're satisfied with your testing and I will merge. Thanks very much.

[endgame]

@ysangkok is there anything else you want to test before I merge?

[ysangkok]

@endgame I was hoping that somebody would get the chance to test in a 'staging' first. Sadly at my work we don't have that infrastructure for the project we use Amazonka for, so I would have to test it in production, which is kinda dangerous. I think it looks fairly safe since the worst case seems to be that it passes a Nothing to serviceError, in place of making all of go a Nothing, which doesn't sound too dangerous, but I haven't looked into it.