Increase timeout in hypothesis for test_apply.py
- [x] passes `git diff upstream/master -u -- "*.py" | flake8 --diff`


In this [build](https://dev.azure.com/pandas-dev/pandas/_build/results?buildId=3781&view=logs)

We see the following error:

`
<pandas.tests.frame.test_apply.TestDataFrameAggregate instance at 0x0000000036892A48>, 2018-11-Unreliable test timings! On an initial run, this test took 631.00ms, which exceeded the deadline of 500.00ms, but on a subsequent run it took 3.00 ms, which did not. If you expect this sort of variability in your test timings, consider turning deadlines off for this test by setting deadline=None.
`

Time difference perhaps due to given parameters for the test case, currently this test case uses the default value which is 500ms. Perhaps I could be more aggressive here and go for 800ms, thoughts? 

Issue introduced in [this change](https://github.com/pandas-dev/pandas/pull/22561) 

Hello @alimcmaster1! Thanks for submitting the PR.

 - There are no PEP8 issues in the file [`pandas/tests/frame/test_apply.py`](https://github.com/alimcmaster1/pandas/blob/332aa541977fa7daf2af4d8a69bbc47eec770f13/pandas/tests/frame/test_apply.py) !

 # [Codecov](https://codecov.io/gh/pandas-dev/pandas/pull/23849?src=pr&el=h1) Report
> Merging [#23849](https://codecov.io/gh/pandas-dev/pandas/pull/23849?src=pr&el=desc) into [master](https://codecov.io/gh/pandas-dev/pandas/commit/e405a105a717f55874ef8d5b4cbcdae0b8a21236?src=pr&el=desc) will **not change** coverage.
> The diff coverage is `n/a`.

[![Impacted file tree graph](https://codecov.io/gh/pandas-dev/pandas/pull/23849/graphs/tree.svg?width=650&token=eZ4WkYLtcO&height=150&src=pr)](https://codecov.io/gh/pandas-dev/pandas/pull/23849?src=pr&el=tree)

```diff
@@           Coverage Diff           @@
##           master   #23849   +/-   ##
=======================================
  Coverage   92.28%   92.28%           
=======================================
  Files         161      161           
  Lines       51500    51500           
=======================================
  Hits        47528    47528           
  Misses       3972     3972
```

| Flag | Coverage Δ | |
|---|---|---|
| #multiple | `90.68% <ø> (ø)` | :arrow_up: |
| #single | `42.31% <ø> (ø)` | :arrow_up: |


------

[Continue to review full report at Codecov](https://codecov.io/gh/pandas-dev/pandas/pull/23849?src=pr&el=continue).
> **Legend** - [Click here to learn more](https://docs.codecov.io/docs/codecov-delta)
> `Δ = absolute <relative> (impact)`, `ø = not affected`, `? = missing data`
> Powered by [Codecov](https://codecov.io/gh/pandas-dev/pandas/pull/23849?src=pr&el=footer). Last update [e405a10...332aa54](https://codecov.io/gh/pandas-dev/pandas/pull/23849?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).
 I feel like it would be better if we could maybe just simplify this test to test the original bug in question. I'm not convinces some of the hypothesis search parameters are entirely necessary e.g. testing a single dtype dataframe with 2 to 5 columns.

This was a minimal example that would test the same bug: https://github.com/pandas-dev/pandas/issues/22150#issuecomment-410319629 Thanks @mroeschke for the thoughts - ill update with a few sensible test case that should clearly highlight the original bug. @mroeschke thoughts on something like this as a replacement test? I varied the number of columns at it was reported in the  issue that the bug was dependent on # of cols.

```
    @pytest.mark.parametrize("num_cols", [2, 3, 5])
    @pytest.mark.parametrize("index",
       [["1950-06-30", "1952-10-24", "1953-05-29"]
    ])
    def test_frequency_is_original(self, index, num_cols):
        index  = pd.DatetimeIndex(index)
        original = index.copy()
        df = DataFrame(1, index=index, columns=range(num_cols))
        df.apply(lambda x: x)
        assert index.freq == original.freq
``` Sure, that test looks good. If we are only testing one `index`, there's probably no need to parametrize over that variable.  I am not sure this will fix some of the recent time out issues, but let's give a try.

@alimcmaster1 also would love a followup based on @mroeschke suggestion here. Yes will do, Thanks! 

Sent from my iPhone

> On 27 Nov 2018, at 01:50, Jeff Reback <notifications@github.com> wrote:
> 
> Merged #23849 into master.
> 
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub, or mute the thread.
