Split EFS from EKS Module

[a13zen]

I just reviewed this module...you are correct that the EFS is indeed created. I would suggest leaving the CNI addon support and just moving the EFS creation to a different module altogether...and parameterize the rest (storage class, etc)

[JunjieTang-D1]

This is a good idea to split EFS from EKS module: we will have S3 connector and EFS as option for different workload

[qvacua]

[x] Changing policy of EFS from DESTROY to RETAIN in core-eks is good to merge
[x] Leave EFS creation in core-eks to support backward compatability
[x] Create new storage module for efs
[x] Create ONE integration module for filesystem support (item #3) for EKS (integration to other services requires a new module)
[x] Multi-version support for core-eks module should be implemented with a 'mapping' of recommend drivers / controllers based on the eks version - and done on an as-needed basis

[dgraeber]

After inspection, the EFS module is fairly simplistic, while the FSx module has many permutations. I would like to give some options about the use case for both in order to determine HOW they should be organized to

1. create the resources
2. integrate with EKS

[dgraeber]

Module to create EFS and to integrate EFS to EKS completed on PR #78

FSx on Lustre support should be in a separate item / issue.