This PR does four things:

1. Repairs some tests
2. Opens up compatibility with more servant-client versions
3. Ups the cabal file spec version
4. Updates dependency bounds

Thanks mostly thanks to the loosening of the servant constraints, I have been able to successfully build this package under GHC 8.6.5, 8.8.4, 8.10.7 and 9.0.1

Tests

The test repairs cover 3 problems:

1. runIntegrationSpec expected SpecWith to satisfy the MonadFail constraint which isn't the case (at least with with modern hspec versions).
2. The /getFile test assumed that it would get a successful response (which wasn't happening).
3. Sticker tests were checking that a returned sticker was correct with an id field that can no-longer be considered unchanging for each sticker, so I added the sticker_file_unique_id field from the current version of the telegram API.

⚠The addition of the sticker_file_unique_id adds to the interface so at least a minor version bump will be required on release.

What this doesn't do is guarantee that all tests are working nor fix all failing tests that may be a result from incompatibilities with the current version of the Telegram API.

Servant-Client Compatibility

Most of the incompatibility seemed to come from dependence on internal servant modules which subsequently underwent minor changes like renamings.

The fixes should be simple and self-explanatory. All tests except 1 passed, which I believe to be is unrelated and caused by an outdated hardcoded file id

  test/TestCore.hs:15:15: 
  1) Main integration tests, /getFile, should get file
       predicate failed on: Left (FailureResponse (Request {requestPath = (BaseUrl {baseUrlScheme = Https, baseUrlHost = "api.telegram.org", baseUrlPort = 443, baseUrlPath = ""},"/bot1159302136:AAG8MeT_d3Ds2gPlso1Zur0yIBVOhR8bztk/getFile"), requestQueryString = fromList [("file_id",Just "AAQEABMXDZEwAARC0Kj3twkzNcMkAAIC")], requestBody = Nothing, requestAccept = fromList [application/json;charset=utf-8,application/json], requestHeaders = fromList []), requestHttpVersion = HTTP/1.1, requestMethod = "GET"} (Response {responseStatusCode = Status {statusCode = 400, statusMessage = "Bad Request"}, responseHeaders = fromList [("Server","nginx/1.18.0"),("Date","Mon, 18 Oct 2021 15:19:34 GMT"),("Content-Type","application/json"),("Content-Length","111"),("Connection","keep-alive"),("Strict-Transport-Security","max-age=31536000; includeSubDomains; preload"),("Access-Control-Allow-Origin","*"),("Access-Control-Expose-Headers","Content-Length,Content-Type,Date,Server,Connection")], responseHttpVersion = HTTP/1.1, responseBody = "{\"ok\":false,\"error_code\":400,\"description\":\"Bad Request: wrong file_id or the file is temporarily unavailable\"}"}))

This fixes #132

To maintain compatibility between both old and new versions of servant I had to resort to a little CPP usage.
I'd prefer to avoid it since in my experience it tends to cause problems with tooling, but dropping compatability with servant-client 0.16 would also drop support with stackage LTS 14, 15 and 16 and therefore support for GHC 8.6 and 8.8 for stackage users.

I expect it may be possible to avoid depending on the internal modules to make this less of an issue.

Upping the Cabal Spec Version

The cabal file was originally on cabal-version >=1.10
Later cabal versions add convenient improvements to cabal file syntax and also provide more information so that tools lik HLS can function, IIRC, such as through the autogen-modules field.

I don't think it likely that there are any users out there who desperately need support for old versions of cabal or stack so I don't think it's too much of an issue to drop support for them.

As such I've upped the cabal-version to 3.4, and made some adjustments to make it compliant.

Dependency bounds.

I have added upper and lower bounds to every library dependency in accordance with the Hackage PVP. This will avoid tools resolving build plans that seem valid but lead to build errors.

These bounds are broad enough to build on GHC 8.6.5 through to GHC 9.0.1 according to my testing.

This fixes #130.

The dependency bounds on servant libs currently look a little odd:

, servant (>= 0.16 && < 0.18) || ^>= 0.18
, servant-client (>= 0.16 && < 0.18) || ^>= 0.18
, servant-client-core (>= 0.16 && < 0.18) || ^>= 0.18

This is because the ^>= 0.18 has subtly different semantics from < 0.19

I could've just done this:

, servant ^>= {0.16, 0.17, 0.18}
, servant-client ^>= {0.16, 0.17, 0.18}
, servant-client-core ^>= {0.16, 0.17, 0.18}

But as more major versions come along those sets are only going to get larger.
I'm happy to change it if preferred.