Tabular: Add available disk logging + warning

[Innixma]

Issue #, if available:

Description of changes:

• Add available disk logging + warning to TabularPredictor.fit call.
• This will highlight to the user when they have small amounts of disk space available.
• If logic errors for whatever reason due to a strange env, it will fallback to a warning message that we were unable to calculating available disk space and asks to submit a GitHub issue and continue.
• Note that the current threshold is 10 GB. This is too high for small datasets, and too low for large datasets, but properly calculating the expected disk space requirement is complex. 10 GB is a good initial value, however it depends on how many models are being trained and what presets are being used. I've added a TODO to improve this estimate in future.

Example:

Low Available Disk:

Beginning AutoGluon training ...
AutoGluon will save models to "AutogluonModels/ag-20230321_214349/"
AutoGluon Version:  0.6.2b20230103
Python Version:     3.8.10
Operating System:   Darwin
Platform Machine:   x86_64
Platform Version:   Darwin Kernel Version 21.6.0: Mon Dec 19 20:44:01 PST 2022; root:xnu-8020.240.18~2/RELEASE_X86_64
Disk Space Avail:   1.50 GB / 499.96 GB (0.3%)
	WARNING: Available disk space is low and there is a risk that AutoGluon will run out of disk during fit, causing an exception. 
	We recommend a minimum available disk space of 10 GB, and large datasets may require more.
Train Data Rows:    39073
Train Data Columns: 14

Standard (sufficient disk space):

Beginning AutoGluon training ...
AutoGluon will save models to "AutogluonModels/ag-20230321_214455/"
AutoGluon Version:  0.6.2b20230103
Python Version:     3.8.10
Operating System:   Darwin
Platform Machine:   x86_64
Platform Version:   Darwin Kernel Version 21.6.0: Mon Dec 19 20:44:01 PST 2022; root:xnu-8020.240.18~2/RELEASE_X86_64
Disk Space Avail:   332.76 GB / 499.96 GB (66.6%)
Train Data Rows:    39073
Train Data Columns: 14

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[gidler]

I notice you created class methods for get_disk_usage_free, get_disk_usage_used, and get_disk_usage_total but just used get_disk_usage and extracted the free and total values. Should we consider deleting the get_disk_usage_{free,used,total} methods if we aren't going to use them, it's easy to extract the members individually, and will avoid multiple calls to shutil.disk_usage?

[Innixma]

good point, I think they aren't necessary, so I've removed them.

[gidler]

Its best to catch as specific of an exception as possible. This would allow us to make the following log statement if the issue is indeed related to the disk_usage call, but if another error is raised in this try block, we don't accidentally hide if from the user. If you know of a more specific exception, it could be good to use it here.

[Innixma]

It is unclear what exception it would raise, as it would require me being able to simulate some strange unknown environment where this logic doesn't work correctly, and the shutil code does not make it clear what exception would be raised in these strange situations. Because of this, it is safest to have a generic exception catch to avoid completely breaking AutoGluon in these more niche scenarios that I don't know about. I'm unsure if these scenarios even exist, but it is very hard to rule out the possibility. (For example, running in the browser, running in colab, running in kaggle, running in docker, running on windows, running on specialized private hardware, running in a fully-in-memory disk environment, etc.)

[Innixma]

Added in-line comment explaining this in the code

[github-actions]

Job PR-3069-88242ab is done.
Docs are uploaded to http://autogluon-staging.s3-website-us-west-2.amazonaws.com/PR-3069/88242ab/index.html

[github-actions]

Job PR-3069-35fb649 is done.
Docs are uploaded to http://autogluon-staging.s3-website-us-west-2.amazonaws.com/PR-3069/35fb649/index.html